M66 Breaks DEBUG in ocode sub
30 Apr 2020 20:58 #166255
by GuiHue
M66 Breaks DEBUG in ocode sub was created 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.
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
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.
- tommylight
- Away
- Moderator
Less
More
- Posts: 18831
- Thank you received: 6324
01 May 2020 00:43 #166268
by tommylight
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
Replied by tommylight on topic M66 Breaks DEBUG in ocode sub
Did you connect E0 to anything in hal ?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.
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.
01 May 2020 08:57 #166293
by GuiHue
Replied by GuiHue on topic M66 Breaks DEBUG in ocode sub
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.
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:).
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.
- tommylight
- Away
- Moderator
Less
More
- Posts: 18831
- Thank you received: 6324
01 May 2020 09:31 #166294
by tommylight
Replied by tommylight on topic M66 Breaks DEBUG in ocode sub
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.
01 May 2020 09:53 #166296
by GuiHue
Replied by GuiHue on topic M66 Breaks DEBUG in ocode sub
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.
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.
- tommylight
- Away
- Moderator
Less
More
- Posts: 18831
- Thank you received: 6324
01 May 2020 10:13 #166297
by tommylight
Replied by tommylight on topic M66 Breaks DEBUG in ocode sub
Just in case you missed it :
linuxcnc.org/docs/html/gcode/m-code.html#mcode:m66
linuxcnc.org/docs/html/gcode/m-code.html#mcode:m66
Please Log in or Create an account to join the conversation.
01 May 2020 18:07 #166349
by GuiHue
Replied by GuiHue on topic M66 Breaks DEBUG in ocode sub
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.
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.
- tommylight
- Away
- Moderator
Less
More
- Posts: 18831
- Thank you received: 6324
01 May 2020 19:02 #166354
by tommylight
Replied by tommylight on topic M66 Breaks DEBUG in ocode sub
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.212 seconds