Project

General

Profile

Actions
Copy link

Bug #77

closed

Have to send job twice?

Added by peteruithoven almost 12 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
firmware
Target version:
-
Start date:
2013-03-13
Due date:
% Done:

0%

Estimated time:

Description

When I'm using Visicut and I just turned on the machine the first time I send a job trough Visicut it never arrives. Visicut will show a progress bar that it's sending, laoslaser display says "it's receiving file...", but it never works. Then after a short while Visicut will think it worked (it didn't) and I can send the job again. Then it works and it sends the job almost instantly. And it keeps working fine as long as I don't shut down the lasercutter.
I have no clue if this is a bug in the laoslaser firmware or in Visicut. Does anyone else have this problem?

I added the info + config file on the list of lasercutters, under Fablab Amersfoort.
http://redmine.laoslaser.org/projects/laos/wiki/A_list_of_users_with_LAOS_converted_lasercutters
I'm using the latest firmware (laoslaser-9-3-2013.bin).

Actions
Copy link
 #1

Updated by parag0n almost 12 years ago

  • Category set to firmware

I'm also getting this problem on our laser cutter.

Sometimes it can take 20 minutes of various reboots to make it accept a file, once it accepts it keeps working until next reset.

I had a look using wireshark, and it seemed that the LAOS board wasn't closing out the TFTP connection correctly. I can upload more information, and the wireshark dump if needed.

Actions
Copy link
 #2

Updated by peteruithoven over 11 years ago

parag0n, please do. I've got no clue how I could debug this otherwise.

Actions
Copy link
 #3

Updated by peteruithoven over 11 years ago

Alright, did some testing, trough a serial monitor, listening to the mbed.
I enabled the TFTP_DEBUG and added some printf's of my own.
I'll add some comments between []'s for clarity.

First time I send a file:

onListenUDPSocketEvent  
  state: 0 [listen]
Listen: Incoming file visicut11.lgc on TFTP connection from 10.0.0.10 clientPort 52455

Main::GetFile()

Second time I send a file:

onListenUDPSocketEvent  
  state: 2 [writing]
Listen: Incoming file visicut12.lgc on TFTP connection from 10.0.0.10 clientPort 52456

onListenUDPSocketEvent  
  state: 2
  0x03 [case handling 0x03]
  data: 7 
Read packet 1 with blocksize = 129

Read last block 129

Third time I send a file:

onListenUDPSocketEvent  
  state: 0
Listen: Incoming file visicut13.lgc on TFTP connection from 10.0.0.10 clientPort 60339

Main::GetFile()

onListenUDPSocketEvent  
  state: 2
  0x03  
  char: 7
Read packet 1 with blocksize = 129

Read last block 129

Fourth time I send a file:

onListenUDPSocketEvent  
  state: 0
Listen: Incoming file visicut14.lgc on TFTP connection from 10.0.0.10 clientPort 58713

Main::GetFile()

onListenUDPSocketEvent  
  state: 2
  0x03  
  char: 7
Read packet 1 with blocksize = 129

Read last block 129

So somehow the onListenUDPSocketEvent isn't called and/or there is something wrong with the state. Sadly enough I don't get enough of the system to debug further. Why is it for example in a writing state? Why does it stay there when you send a new file?
How can I simply print what comes in?

Actions
Copy link
 #4

Updated by DeanoC over 11 years ago

Also getting similar issues, making it really hard to use.

Actions
Copy link
 #5

Updated by peteruithoven about 11 years ago

Using the MBED compiled firmware seems to mostly solve the issue. Especially the consistent first time send issue seems gone. Awesome side benefit to using the MBED compilation method.

Actions
Copy link
 #6

Updated by peteruithoven over 10 years ago

  • Status changed from New to Closed

As far as I can tell after using the new version in our Fablab for quite a while this issue seems solved.

Actions
Copy link

Also available in: Atom PDF