Remap of M6 not working correctly

More
06 Nov 2024 17:00 #313925 by viesturs.lacis
Hello!

I am trying to implement a remap of M6 command as a part of a Biesse retrofit. I am running 2.9.3 on Bookworm.
The machine has 5 tool posts that can be considered as a tool rack (each tool post raises/retracts with pneumatic cylinder and some other bells and whistles but principle remains) as well as 26 vertical drills and 4 horizontal drill heads where drill bit can be inserted on both sides to drill a workpiece from all 4 sides.
Remap is through g-code routines with tool_change.ngc as main subroutine that calls either tool_put_move.ngc or tool_get_move.ngc for unloading or loading tool respectively. These files are copied (with minor edits of XYZ coordinates etc) from previous retrofit of almost identical Biesse that I did few years ago.
I have tool 1 in spindle on startup so I run "M61 Q1" in MDI and then I run M6 T2. Nothing happens - no motion, nothing at all, on very top of Axis GUI I see that it is in tool_put_move.ngc. Printed messages in terminal are shown in attached picture.
I see several issues:
1) (MSG, whatever text) or (DEBUG, whatever text) in the ngc file does not display the respective message in Axis GUI. Only way to get some message so that I can follow the actual execution of code is with (print, whatever text)
2) Line 27 and Line 29 from tool_put_move.ngc are about printing message in terminal. But the move in line 28 is not executed which makes no sense to me as it is straight linear move.

I tried in MDI - those M64 P3 and other commands do work properly in terms of switching the actual solenoid valves

I have attached the screenshot as well as the config. Subroutines are in nc_subroutines folder in config.
I would appreciate any hints what am I missing or doing wrong.

Viesturs
Attachments:

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

More
06 Nov 2024 19:50 #313947 by rene-dev
Try t2m6

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

More
07 Nov 2024 07:08 - 07 Nov 2024 07:15 #313991 by Aciera
Regarding MSG/DEBUG vs PRINT:
Note that (PRINT, sometext) will be executed by the interpreter read-ahead while (MSG, sometext) and (DEBUG, sometext) messages are put in the queue and will execute during gcode execution.  

If you want your (PRINT, sometext) method to work correctly you should use an if statement to only execute it in task mode
and use a queuebuster command before to stop the read-ahead
o111 if [#<_task> EQ 1]
  M66 E0 L0 ; queuebuster will stop the read-ahead here
  (print, sometext)
o111 endif

So if your PRINT messages are displayed  but the MSG/DEBUG messages are not then the read-ahead has ingested the (PRINT, sometext) lines but Gcode execution did not reach the (MSG, sometext)/(DEBUG, sometext) lines in the program.
Last edit: 07 Nov 2024 07:15 by Aciera.

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

More
07 Nov 2024 07:20 #313992 by viesturs.lacis
Aciera thank you for explanation!
Then something is wrong there because this is beginning of tool_change.ngc (which is main subroutine for tool change procedure):

o<tool_change> sub

M73 (auto-restore modal settings on return)

(MSG, Tool change: loaded tool=#<_current_tool>)
(MSG, Tool change: selected tool=#<_selected_tool>)

(print, rack_change: loaded tool=#<_current_tool> current pocket: #<_current_pocket>)
(print, rack_change: selected tool=#<_selected_tool> selected pocket: #<_selected_pocket>)

; unload previous tool - if next tool is also in spindle 1, then have to actually unload it first, so second parameter for tool_put_move is 0;
o100 if [#<_current_tool> GT 0]
o101 if [#<_current_tool> LE 5]
o102 if [#<_selected_tool> LE 5]
o<tool_put_move> call [#<_current_tool>] [0]
o102 else
[code continues but it I am now testing with a scenario that "o102 if" statement is true and <tool_put_move> subroutine is called with first parameter as current tool number and second parameter as 0]

I get to the point where a next subroutine is called so I would expect ALL the lines before that to be executed but those (MSG) messages are not displayed.

How do I check of what exactly is wrong?

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

More
07 Nov 2024 07:39 #313994 by Aciera
It's important to think of the interpreter read-ahead when you work with Gcode that depends on parameter values.

Try inserting a queuebuster before the M73 ..
M66 E0 L0
M73 (auto-restore modal settings on return)

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

More
07 Nov 2024 09:39 #314003 by viesturs.lacis
I did insert G0 G53 X20 Y20 Z80 right after that M73 and the move is not executed. Ok, I will go back now and try your suggestion.

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

More
07 Nov 2024 11:01 #314006 by viesturs.lacis
Ok so what I did and what whas the result is shown in 2 pictures attached.
In the tool_change.ngc I added following lines so that the beginning was this:
o<tool_change> sub

(print, tool_change started)

M66 E0 L0
(print, tool_change after 1st queuebuster)

M73 (auto-restore modal settings on return)
M66 E0 L0
(print, tool_change after 2nd queuebuster)
G0 G53 X20 Y20 Z80
M66 E0 L0
(print, tool_change after 3rd queuebuster)

(MSG, Tool change: loaded tool=#<_current_tool> )
(MSG, Tool change: selected tool=#<_selected_tool> )
M66 E0 L0
(print, tool_change after 4th queuebuster)

The result is that in the terminal only the first message is posted. Meaning that it did not get past that queuebuster line. What was expected behavior there? I do not have anything connected to motion.analog-in-00 so I would expect it to read value "zero" and move on...
Attachments:

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

More
07 Nov 2024 12:49 #314008 by Aciera
'tool_change started' was printed when the read-ahead ingested that line and then it stopped reading due to the queuebuster and waited for code execution to catch up. What this means is that the actual code execution does not reach the 'tool_change' subroutine.
Not sure what's going on but whatever it is it does not seem to be a problem in 'tool_change.ngc'.

Have you tried calling that subroutine directly from MDI:
o<tool_change> call

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

More
07 Nov 2024 12:55 #314009 by Aciera
Just noticed this, there are two ini files in that config. Are you running 'Biesse.ini' or ''racktoolchange.ini'?

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

More
07 Nov 2024 13:02 - 07 Nov 2024 13:04 #314010 by Aciera
The other thing (but maybe of no importance here) is that your ini files use FEATURES in the [RS274NGC] section
# turn on all optional features except RETAIN_G43
FEATURES= 30


which has been replaced by individual entries:

 

 
Attachments:
Last edit: 07 Nov 2024 13:04 by Aciera.

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

Time to create page: 0.105 seconds
Powered by Kunena Forum