File Not Open error.

[perfectphase]

FB: 440.20 Give I'm at X=-1.00, in G90 I submit 'G1 F100 X0.01' I get a returned 'r', 'sr' and 'qr' reports. I then resend 'G1 F100 X0.01' I get returned 'r' and 'sr' (no motion occurred, motors did not power up) I now close the serial port and reconnect I issue an fv query and I'm returned the error { "er": {"fb": 440.2,"st": 9,"msg": "File not open" }}

[ril3y]

Can you issue a $$ and paste the output? After that can you do the following?

This will reset you to default settings.

Try this

$defa=1

On Mon, Dec 14, 2015 at 4:09 PM, perfectphase notifications@github.com wrote:

FB: 44020 Give I'm at X=-100, in G90 I submit 'G1 F100 X001' I get a returned 'r', 'sr' and 'qr' reports I then resend 'G1 F100 X001' I get returned 'r' and 'sr' (no motion occurred, motors did not power up) I now close the serial port and reconnect I issue an fv query and I'm returned the error { "er": {"fb": 4402,"st": 9,"msg": "File not open" }}

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/148.

[rickcaddell]

[fb] firmware build 440.20 [fv] firmware version 0.97 [hp] hardware platform 1.00 [hv] hardware version 8.00

I get the same error (FIle not open) when I issue a Gcode command to change the coordinate system (ie. G55 or G56) if after a move has been done. For example, if I reset the TinyG I can send G55 thru G59 all day with no problem, but after a move, a G55 thru G59 will cause the "File not open" command. I wait for a few seconds after the move to make sure it is done. I read somewhere that this error can be caused by trying to change the EEPROM during a move. I think that there must be a flag that gets set during a motion that is not getting properly reset.

This is what happens before a move: {gc:"G55"} {sr:{line:t,posx:t,posy:t,posz:t,mpox:t,mpoy:t,mpoz:t,vel:t,stat:t,coor:t,unit:t}} {"r":{"gc":"G55"},"f":[1,0,11,5609]} {"sr":{"line":0,"posx":-1.000,"posy":-2.000,"posz":-3.000,"mpox":0.000,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}} {"r":{"sr":{"line":0,"posx":-1.000,"posy":-2.000,"posz":-3.000,"mpox":0.000,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}},"f":[1,0,83,5057]} {"sr":{"line":0,"posx":-1.000,"posy":-2.000,"posz":-3.000,"mpox":0.000,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}}

This is what happens after a move {gc:"G55"} {sr:{line:t,posx:t,posy:t,posz:t,mpox:t,mpoy:t,mpoz:t,vel:t,stat:t,coor:t,unit:t}} {"r":{"gc":"G55"},"f":[1,0,11,5609]} {"sr":{"line":0,"posx":-0.990,"posy":-2.000,"posz":-3.000,"mpox":0.254,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"er":{"fb":440.20,"st":9,"msg":"File not open"}} {"r":{"sr":{"line":0,"posx":-0.990,"posy":-2.000,"posz":-3.000,"mpox":0.254,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}},"f":[1,0,83,3085]} {"sr":{"line":0,"posx":-0.990,"posy":-2.000,"posz":-3.000,"mpox":0.254,"mpoy":0.000,"mpoz":0.000,"vel":0.00,"stat":3,"coor":2,"unit":0}}

[ril3y]

Oh TinyG v8's and below. They all use the XMEGA192A3. This uC has a bug in it that when writing to the EEPROM you have to disable interrupts. So TInyG does all this for us. However, you should never write to the eeprom during moves of times where you are getting massive status reports back etc. This might be what is causing this type of behavior.

When writing to the eeprom, its best to wait for the return status report that the value was set before continuing to blast it with more serial data. Not sure if this is the issue or not.

[Pandersonjr]

Hi- i have written synthetos contact us and also on the synthetos foum regarding a replacement board and still havent been contacted back. (this was a few weeks ago) Is this the way to get ahold of someone? On Dec 22, 2015 4:50 PM, "ril3y" notifications@github.com wrote:

Oh TinyG v8's and below. They all use the XMEGA192A3. This uC has a bug in it that when writing to the EEPROM you have to disable interrupts. So TInyG does all this for us. However, you should never write to the eeprom during moves of times where you are getting massive status reports back etc. This might be what is causing this type of behavior.

When writing to the eeprom, its best to wait for the return status report that the value was set before continuing to blast it with more serial data. Not sure if this is the issue or not.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/148#issuecomment-166739904.

[rickcaddell]

OK I tried making sure no messages are sent until the return status and that worked. Thanks

[ril3y]

Pandersonjr,

There was a issue with our contact us page. However its working now. If you send us another message we can get you fixed up now.

I hope that helps.

Riley

On Tue, Dec 22, 2015 at 5:25 PM, Pandersonjr notifications@github.com wrote:

Hi- i have written synthetos contact us and also on the synthetos foum regarding a replacement board and still havent been contacted back. (this was a few weeks ago) Is this the way to get ahold of someone? On Dec 22, 2015 4:50 PM, "ril3y" notifications@github.com wrote:

Oh TinyG v8's and below. They all use the XMEGA192A3. This uC has a bug in it that when writing to the EEPROM you have to disable interrupts. So TInyG does all this for us. However, you should never write to the eeprom during moves of times where you are getting massive status reports back etc. This might be what is causing this type of behavior.

When writing to the eeprom, its best to wait for the return status report that the value was set before continuing to blast it with more serial data. Not sure if this is the issue or not.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/148#issuecomment-166739904.

— Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/148#issuecomment-166750666.

[ril3y]

Specifically here panderson: https://www.synthetos.com/contact-us/