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.

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.

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.