M66 Breaks DEBUG in ocode sub

More
30 Apr 2020 20:58 #166255 by GuiHue
Hi everyone,

I have been chasing a rather strange behaviour the past two nights.

Let's take a macro that has been stripped of everything useful.
o<rack_change> sub
(DEBUG, A test message before we launch M66)
M66 E0
(DEBUG, value M66 #5399)
(print, value M66 #5399)
o<rack_change> endsub [1]
M2
%

If I launch this as a part of my M6 remap, I will get a DEBUG Message "A test message before we launch M66" and then nothing.
However, if I remove the M66 the second DEBUG will display. The same holds true in more complex macros. Once I use an M66 no further "debug" messages will be triggered. However, Messages using "print" will be sent to the terminal.

I guess I am missing something, but my google-fu failed me miserably.

Any ideas?

BR
Guido


I am on:
Debian 9, Buildbot Master, Gmoccapy 3

Please Log in or Create an account to join the conversation.

More
01 May 2020 00:43 #166268 by tommylight

GuiHue wrote: If I launch this as a part of my M6 remap, I will get a DEBUG Message "A test message before we launch M66" and then nothing.

Did you connect E0 to anything in hal ?
M66 is wait for input and E0 is digital input 0, so if it is not connected to anything that has to change in hal or a physical input, it is doing what it should: waiting.
linuxcnc.org/docs/html/gcode/m-code.html

Please Log in or Create an account to join the conversation.

More
01 May 2020 08:57 #166293 by GuiHue
Hey Tommy,

E0 is indeed connected and will return a signal. The print statement (print, value M66 #5399) confirms this and yields the correct value.
net toolprepnumber       probe.toolchange-number <=   iocontrol.0.tool-prep-number
addf s32float.tool servo-thread
net pocketprepnumer s32float.tool.in
net transferpocket2 s32float.tool.out motion.analog-in-00

It is worth pointing out that in a more complex macro which has multiple lines of movement after M66 all of these movements are executed. This is sort of why I am lost:).

Please Log in or Create an account to join the conversation.

More
01 May 2020 09:31 #166294 by tommylight
Use halshow from the machine menu to check if that pin/input changes state while executing that macro.
The following user(s) said Thank You: GuiHue

Please Log in or Create an account to join the conversation.

More
01 May 2020 09:53 #166296 by GuiHue
Thank you. I'll have a look into this. It does, however, make me wonder a bit. Isn't M66 on an analog pin just doing an instantaneous read without waiting for a change?

In the specific case, the pin will not change, as it has been set prior to executing the macro and is used to get a correct pocket number as a hotfix for the current dilemma with pocket number handling.

If I use M66 E0 L0 it doesn't change the behavior either.

Please Log in or Create an account to join the conversation.

More
01 May 2020 10:13 #166297 by tommylight

Please Log in or Create an account to join the conversation.

More
01 May 2020 18:07 #166349 by GuiHue
Hey Tommy,

I guess I did miss it. Till now I still don't get which specific aspect you re pointing me too.

Never the less, I have since made some progress. I added L0 to M66 E0. I might have missed that last night, though I thought I had tried that.

There is a another relation that I worked out. In the large macro there are numbers if conditionals which, when true, are supposed to stop the macro. I had used M2 commands at those places. I have since changed all those M2 to o<number, e.g. 110> return [999] commands. Since then, the entire macro seems to work just fine.
The following user(s) said Thank You: tommylight

Please Log in or Create an account to join the conversation.

More
01 May 2020 19:02 #166354 by tommylight
Glad you got it working and thanks for reporting back.
The following user(s) said Thank You: GuiHue

Please Log in or Create an account to join the conversation.

Time to create page: 0.105 seconds
Powered by Kunena Forum