What signals can cause a move instruction to stall indefinitely?

This is a distillation of the issue I first posted about in my thread "Mysterious interaction...etc". I'm starting a new thread because now I have a clearer understanding of the conditions that cause the issue I think the old title and original post just obfuscate things and the thread is now superfluous.

What I am describing here was established typing gcode instructions directly using the MDI command interface in axis, but it happens running full programs too.

My system (Denford 2600 controlled with a Mesa board) sometimes stalls on move instructions, despite what I posted before the coordinate mode does not matter, G54 or G53 gives the same results.

When it stalls, hitting the program stop button and then repeating the same instruction will then work fine.

But, it seems this happens in a very specific circumstance, which is why I didn't encounter it until I implemented a splindle warmup procedure as stipulated in the Denford manual.

The problem will occur in I start and stop the spindle WITHOUT moving the carriage while the spindle is spinning.

So, if I do 

S1000 M3
M5 (Stop spindle without having gone anywhere)
G0 X200 F3000 (This will stall, must press the program stop button to regain control)
G0 X200 F3000 (This will work)

However if I do

S1000 M3
G0 X190 F3000 (Move while the spindle is spinning)
M5
G0 X200 (This will work)

There is one other scenario I have found which causes the issue, and that is when I turn on the spindle but don't actually set a speed high enough for it to start turning, so
S200 M3 (too slow)
G0 X190 F3000. (This will stall)

One other possibly useful piece of information is that if the carriage is already at the destination location, the move instruction will not stall, it will just pass through (doing nothing of course as there is no move needed().

So it seems to me that when a move instruction is issued the system (linuxcnc or mesa card, I don't know how much of the operation happens in each) is waiting on some signal which is somehow latching into the wrong state in the above scenarios. Does anybody have any idea what it might be?

Failing that, perhaps if someone could point me to where in the gcode interpreter these instructions are handled I can do some further investigation myself.

 

Can you post your hal and ini files?

It sort of sounds like some issue with spindle-at-speed

These are my main hal and ini files, plus a hal file for a gladevcp panel that displays spindle at speed in case I misunderstood the side effects of that net command

 

Also what does G0 Fxxx mean?
Does feed rate mean anything to G0 moves?

I can't actually remember if it was essential at that point. In my various experiments I had an error of not having a feed rate pop up so I just got into the habit of putting them on every move as it didn't seem to hurt
Also I can't recall for sure if G1 moves gave the same result, I can do further tests but not until later tonight

Ok, so I just checked

The G0 commands don't need an Fxxx

But G1 moves (which need at least one feed rate command) seem to suffer from the exact same stalling issues

Also, just to let you know, spindle-at-speed does get triggered correctly by the vfd

Keyboard noise issues?

Have you tried launching LinuxCNC from the command line to see if any
messages are printed?

I have been assuming that the interpreter stalled (no motion in the backplot)

Is this the case?

If I'm understanding the question correctly, yes it is the interpreter.

I execute the instruction and nothing seems to happen, then I hit the interpreter stop button and execute the same instruction, and it works fine