File not open error

> Did you hand edit the {“zsn”,0} JSON command into the Gcode file (to turn off the limit switch) ?

No, but I wrote the program that is talking to TinyG. I'm not sending a file, my program is talking to TinyG in real time. At this point, it is trying to probe down (in my case, to +Z direction), therefore it is changing the switch settings.

> When the GCode is being sent, I believe tinyG is in text mode.

Doesn't seem so; at least the responses are in JSON. Anyway, sending the switch command in text mode gives the same error.

The error does not seem to depend on JSON vs text mode.

I converted the communications to be all JSON. The error stays.
Also, it is not timing dependent; if I pause between commands or give them manually, it still crashes.

Alden, what might cause "file not open" error?

Hi, although I am not Alden I can try to give more information on the error because I have been tinkering with the code for other reasons.

The file not open error is returned when someone tries to change values in EEPROM while the machine is moving (for EEPROM writes, interrupts have to be disabled for a "long" time which would mess up step pulses etc). The new value is still being set, but not written back to EEPROM, so the old value will be used after you reset the tinyg.

The machining state is correctly set when the machine is moving, and also correctly reset when the movement is finished. The funny thing (aka bug) is that it is also set when M8 (or any other M command) is executed after the movement stops. It is only reset when another movement is started and finished.

Possible workarounds for you:
- ignore the error (should not hurt you if the $zsn value is always under control of your program, but certainly not pretty)
- reset $zsn before executing M8. Your program seems to wait anyway until movement is finished, so you should not get the error any more.

Thank you! This was the issue. I was able to re-arrange my code so, that all M commands are followed by a real move.

Was this issue ever fixed other than by careful rearrangement of the commands?
I am writing something similar to JuKu where I issue commands in realtime to the TinyG. This is for a jog feature.

To implement it, I do the following:
1) record the maximum travel velocities of all the axes (XVM, YVM);
2) detect an arrow keydown event;
3) reset the velocity of the axis of move direction to 1/10 of the original;
4) issue a move to maximum travel distance in the desired direction;
5) detect a keyup event;
6) issue a "!%" to cancel the move and clear the buffer;
7) reset the travel velocities (X and Y) to the original values (using XVM, YVM).

After issuing the last XVM and YXM commands, I get:
{"er":{"fb":438.02,"st":9,"msg":"File not open"}}

Attached, is a screenshot of my app showing the commands sent and responses received.
[image: tinygerr.png, no longer available]
I suppose that I could issue dummy move commands between the velocity resets but that seems like a bandaid approach. I also know that I am not using the most recent firmware version.

Any ideas on the best way to resolve this?

Thanks,
James

OK. Let me try that.

BTW, if John Lauer monitors this forum, I think this is a better approach than what he is using to jog in Chilipeppr. He issues a series of G91 and G90 commands as long as the key is depressed (the keydown event issues one and, as long and the key is held down, there are are series of keypress events that result in more commands being issued). At least on my machine, that leads to a very stuttering type of movement.

The approach I am trying gives you smooth movement. You detect keydown, ignore all keypress, and detect keyup events. As long as the travel rate is fairly slow, you get smooth movement and control.