please note - I did the original diagnosis and initial code you referred to
however, the current code in master was worked over by Seb, you might want to
talk to him
I am unclear about the status - the way I understand it is that there is
currently no backpressure mechanism on the MDI queue
-
I found:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/emc/task/emctaskmain.cc;h=e6a93ed5cdf1a1ae6886398f1453eabf2ce95df6;hb=d4d4b07fb3a95459c5e41069825a5036e127586a#l3171
(it can help))
--
Rapidly troubleshoot
I have another idea:
I wanted to do the reverse Gcode (using commands MDI)
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
Hi all!
I used the same approach as Kirk, but I've found some interesting
behaviour when running this subroutine file: If no program file is
loaded at the moment the MDI command is issued, it fails with the error
message "Unable to open file " (or similar wording, can't test it
right now).
Do you
On 12/29/2013 10:17 AM, Konstantin Navrockiy wrote:
> I try to give few commands MDI,
> error:
> 'maximum number of queued MDI commands exceeded'
> how to fix it?
... snip
I may have had a similar problem to yours. I fixed it by creating an 'o'
subroutine file, then calling the file from the MDI
I try to give few commands MDI,
error:
'maximum number of queued MDI commands exceeded'
how to fix it?
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of
