Is it a hal setup error?

For Mesa FPGA cards you need to know the GPIO pin number
for the pin and to set that GPIO pin into output mode.

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

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.
 

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


 

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.

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.