Advanced Search

Does the machine have a physical e-stop?
What comms between RPI and control board?

Hi,

I have a PrintNC machine with a Flexi-HAL board, and installed the customized Expatria LinuxCNC image (github.com/Expatria-Technologies/Flexi-Pi) on a Pi5, then upgraded LinuxCNC to 2.9.8. It all works fine.
I have the Pi5 with an SSD as well as an SD card, so I can kind of multiboot, and the above mentioned setup is on the SSD. I wanted to move from bookworm to trixie, so imaged the SD card with the latest trixie based LinuxCNC image (github.com/LinuxCNC/linuxcnc/releases/do...9.8_arm64_trixie.deb), and copied all the linuxcnc configuration over from the SSD.

LinuxCNC starts with the same configuration, but I cannot get out of ESTOP. I click the big red ESTOP button (using qtdragon_hd), but nothing happens.

Any advise what I can look at?

Thank you in advance!

Hey everyone,

I'm stuck with a weird problem and could use some advice.

I've got a 3-axis mill with a 1.8kW AC servo on the spindle. It used to run perfectly from a parallel port and a Chinese BOB. I'm now upgrading to a Mesa 7i92, still using the same BOB.

To reverse the spindle I've always used a PC817 optocoupler module. When the REV signal is active, the module pulls the servo driver's DI4 pin to GND, and the spindle reverses. Simple.

Now with the 7i92, everything else works (motion, outputs, etc.), but the spindle reversal doesn't. The LED on the PC817 module lights up when REV is on, but the spindle doesn't reverse. If I take a piece of wire and manually jumper DI4 to GND, it reverses instantly. I've even tried a brand new PC817 module – same behavior.

Wiring of the PC817:

Input side: IN → pin 9 of the BOB, GND → BOB GND

Output side: V (collector/output) → DI4 on the servo driver, GND → servo driver GND

The BOB GND and the servo driver GND are common.

What puzzles me is that this exact setup worked fine with the parallel port. Why would the 7i92 cause a problem with the same BOB and wiring? Is there something different about the 7i92 outputs that could mess with the PC817?

 Is there a better or more reliable alternative to these PC817 modules for this kind of level shifting?

Thanks in advance

There are many ways of doing things in Linux and LinuxCNC, so i'll just throw this out there:
-you can have many configs for the same machine-in your case you can have PyVCP panels for chairs in one config, for beds on another config, etc, etc, as many as you care to make
-each of those configs can have it's own working directory to read files and/or MDI/O calls, etc
-each of those configs can also have it's own limits and/or speeds and/or accelerations and/or ... whatever you need
Any many more options, frankly hard to recall all at once here so i am sure i might find more later.

You can call offsets and subroutines with a variable:
Just some example

;select G54
#<ucs> = 54
G#<ucs>

;select from G54 to G57
#<job> = 0
o100 REPEAT[4]
#<job> = [#<job> + 1]
#<ucs> = [53 + #<job>]
G#<ucs>
o100 ENDREPEAT

and you can call numbered subroutines

#<job> = 1
#1234 = #<job>
o#1234 call

and the subroutine would be
1.ngc

o<1> sub

your code

o<1> endsub
M2

It should be possible to assign offset and call the required subroutines with variables

No, it's more like I have a production run for a customer and I'd like to batch up 4 jobs at a time on the bed, but each job has its own gcode file.  So I need a script that runs each gcode file with the right work offset for each of the 4 setups.

(in this case, it's two parts for a chair, each part is different on both sides, and each pair of parts is a mirror image of the other, so four gcode files - but two runs produces four finished parts)

I expected to find some easy way of "batching" jobs like this, without mixing files from different jobs together on disk, but didn't.  Also, my memory is not good enough to trust doing any part of this manually, I want all the commands to be in one "project" gcode file that I can just run and it does the right thing.

And yes, I could have each setup be a different G54 et al (assuming few enough jobs that there are enough G5*) but I still need a way to run all four of them without having to go to the machine and remember which one is next.
 

Note that 'genhexkins' is meant for hexapods, which may or may not be what you are using.
linuxcnc.org/docs/html/man/man9/kins.9.h...Hexapod%20Kinematics
 

PS. If I happened to have a 5i22 and daughter/breakout boards to go with it, I would be more inclined to try to use it than to try to sell it. Especially if I were planning a Linuxcnc related project.

hello gentelmen,

Does somebody have time to help me tested some behaviour of the actual trajectory planner(trapeziodal)? maybe there is bug in the TP and I need more independent observations ... 

Its just regular simulation setup with some precise steps to replicate ... the post the picture of the watched scope please

I need help from you please...

If you are ready, create axis.ini sim OR sim axis_mm.ini trivkins simulation UI ... then

• Start Lcnc
• Enable
• home all
• hal scope
• observation time as long as possible but period is fine 40ms
• add joint.0.vel-cmd.. scale 20
• add joint.1.vel-cmd.. scale 20
• split them to they own space
• Load Gcode program(from attachements but watched behaviour is present everywhere)
• hit play button alias program run
• observations the spline created by gcode (nice smooth steady - the first one)
• wait program end OR stop program by program stop/stop radio button
• break point 1(only for repeat command)
• return home G28 or rehome everything
• I press start button again at same code no change, no position change nothing just return to row 1 of gcode
• start program with play radio button
• observations the spline created by gcode (clingy - every other)
• wait program end OR stop program by program stop/stop radio button
• go to breakpoint 1(only for repeat command)

Please paste your scopes ... I hope your velocity splines will be exact same at rerun the gcode!!!

My scope is at rerun different each time ... 

many thanks


 

For a simple example of a switchable kinematics component see:
github.com/LinuxCNC/linuxcnc/blob/master...onents/millturn.comp
This is the kinematics used in the simulation config at 'configs/sim/axis/vismach/millturn'

For a more complex but fully documented example that might even cover your use case this might be of interest:
forum.linuxcnc.org/show-your-stuff/49103...-head?start=0#271334
The two kinematic models presented in the zip folder attached to the above post can do a fair bit more than what you need but together with the documentation it will give you an in depth introduction on how to build your own kinematic components.



For documentation on building linuxcnc on your local machine (RIP):
linuxcnc.org/docs/html/code/building-linuxcnc.html

Hi Stepperonline Thank you very much for the guide, and a warm welcome to the forum. I hope you’ll be able to help us with any questions we have on the forum.

If you are using Gmoccapy then you can use the 'gmoccapy.program.progress' halpin which is created by the GUI.

 

This was my thinking to get the program length if it was not being computed.

Is there a way of accessing "program.length" to set a global # parameter, say #1100 (#1100 = halcomp["program.length"] or is there a way to access halcomp["program.length"] inside of gCode?

Or better yet, is program progress being computed by gmoccapy which can be connected to an analog output, say motion.analog-out-01? This would be preferred since no additional lines need to be added a gcode file to track progress., just a HAL connection to the display widget.

Thanks for that @rodw. your contributions in this forum is a godsend. I am still a newbie, nonetheless plan on contributing as much as i can.

The geometry makes sense, i didn't struggle with that. i always unfolded the pipe in my head. the geometry of the pipe is the same but i guess the g-code produced by the CAM is different.

In option 1, where the pipe is on a chuck its a mere single axis rotation command of -60 degrees, and then a movement along the x-joint for notch.

In option 2, the torch would have to maneuver along the pipe which is both a y-axis, z-axis movement, and also c-axis rotation, then a movement along the x-axis for a notch.

Writing all of this has made me realize it is CAM dependent as you said. so nothing would change but I would need to use the genhexkins for full 6-axis. I'll have a go at it then.

Hello Aceiera,

Can you help modifying this Kinematics which I can compile as .comp file, I'm Total noob to understand RIP installation.

Any documentation or guide, for RIP in 2.9.8.


Thanks in advance