Advanced Search

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:
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...

@Aleksamc,

But maybe it will be never realized
The linuxcnc sai lib, can maybe run multiple instances of the interpreter.
But that's not tested as this point.
The rs297 lib is tangled with python. Linked to many other lcnc libs.
This makes it hard to decouple and test it stand alone.

But you make it so easy!!! I very impressed about that!
The hardest part to figur out where the "unlimited" nested while loops.
Parsing a raw gcode file to something the interpreter can read is not that hard.

@Spumco,
Such as X1/X2, Y1/Y2, Z1/Z2, C1/C2, etc.
As i understand you want to send a X2 from master to slave machine directly in the gcode.

This is not realised yet. And i think the command should look a little different as the slave's have a name.

prototype : [Command_id] [Name] [Command]

Then you should send a command like "G200 n2 G0 X100 Y100 Z100 C0".
or something like  "SEND n2 G0 X100 Y100 Z100 C0".

Where G200 is a chosen as command_id.
Where n2 is the name of the duplicated axes (XYZC).

@Arciera,
That's exactly how it is!
And it's not easy to code this into lcnc. As everything is based on one instance of lcnc.

However it's interesting to try  to setup multiple hal environments.

This is an idea of how it might work:

Websocket line
    |
    | - GUI Application (websocket client) (user land)
    | - HAL Environment A    (Super-Imposed Interpreter) (websocket server) (kernel space)                    
    | - HAL Environment B    (Machine controller 1) (websocket client) (kernel space) -|
    | - HAL Environment C    (Machine controller 2) (websocket client) (kernel space) -|
    | - HAL Environment D    (Machine controller 3) (websocket client) (kernel space) -|
                                                                                                                                                      |    
                                                                                                                                                      |
                                                                                                                                             Ethercat bus

** Ps, Relating the the lcnc trajectory's planner, soon i have to make a opencascade viewer to check the fillet output's made
in the tpmod.so component. As i can not see anything now.

 

Are the linux commands the problem?

Please use:
sudo apt install linuxcnc-uspace-dev
sudo apt install build-essential

sudo halcompile --install udp.comp

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.

Check the green/black header.

That is called a "rack tool changer", i am pretty sure it can be controlled with gcode only, not sure if it needs remaping (i guess it would), so it should be easy to do, although i never tried it.
forum.linuxcnc.org/20-g-code/36441-anyon...-length-probe#131714

You might want to have a look at the example config in 'configs/sim/axis/remap/rack-toolchange' as a starting point.

Note the custom entries at the bottom of the inifile:
github.com/LinuxCNC/linuxcnc/blob/master...e/racktoolchange.ini
and the ngc remap:

github.com/LinuxCNC/linuxcnc/blob/master...ines/rack_change.ngc

I have a spindle equipped with this feature for pidconnection to a relay. I need an approximate code M6 for linear tool change

Hm, as I understand it, this does _not_ give us multi thread gcode execution as that would require multiple parallel motion planners in the same linuxcnc instance. A single instance of linuxcnc cannot interpolate more than one tool path at the same time.

Thank you all.
So, I will give it a try. As far as I can see there is no header on the motherboard (small form factor).

sudo gdebi linuxcnc_2.9.3_amd64.deb
In the same folder where the downloaded files are.

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 ..

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?

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

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.

If you go with a sensor and use a analog input then we can rewrite the code to use a high and low pressure setting.