Advanced Search

Searching Google for an answer to this issue it suggested to put a system command in the shutdown.hal file and set the .ini parameter:

SHUTDOWN = shutdown.hal

which I have done.

I've created a bash command script, killglade, which if run from the command line kills the orphaned glade panel. In my shutdown.hal file I have the following command:

system killglade

That is pure AI generated nonsense. There is no hal command 'system':
www.linuxcnc.org/docs/stable/html/hal/ba...tml#sec:hal-commands

What you could try is start your configuration through bash and have your killglade script execute after linuxcnc is shut down:

I am not. I just read trivkins and it also supports xyzabc. so ill have a go at that.

Since I had the flexi-pi image on the SSD, I booted it, started linuxcnc in debug mode and saved the output.
I then booted the new LinuxCNC image from, the SD card, and did the same. Started linuxcnc in debug mode and saved the output.
Since the SSD is always connected, I mounted it, and so I could compare the debug output. The only difference was these lines.I don't know where to get this ;library from, I thought it would be part of the "flexi" component that comes withe flexi-pi image.

Searching Google for an answer to this issue it suggested to put a system command in the shutdown.hal file and set the .ini parameter:

SHUTDOWN = shutdown.hal

which I have done.

I've created a bash command script, killglade, which if run from the command line kills the orphaned glade panel.  In my shutdown.hal file I have the following command:

system killglade

However, the panel is not stopped upon shutdown of gmoccapy. The documentation from the web mentioned that the bash script should be in the configuration directory. While not technically in the configuration directory I created a soft link to the actual file which is in my ~/bin directory which in turn is in my search path so the file can be executed from anywhere.

Does anyone have an idea what I may be missing or any insight into running bash scripts with the system command in the shutdown.hal file?

I've attached my killglade script and my shutdown.hal file for your reference. 

Yes, there is an ESTOP input on the board, but it is not triggered.

The communication between the RPi5 and the board is SPI. The firmware flashed is a customized version of remora-spi, tailored for the Flexi-HAL board by Expatria (github.com/Expatria-Technologies/remora-flexi-hal).

I don't think there is anything is wrong with the board. As I said, I have multiboot set up with an SSD and an SD card, and I have the customized linuxcnc image on the SSD from Expatria (github.com/Expatria-Technologies/Flexi-Pi). If I boot that, everything works.

My best guess is that it is the communication between the board and the Pi through SPI that isn't working for some reason.

Can you check the output of the module with an ohmmeter?

If the PC817 module needs 5V drive you would have to connect it in sinking
mode to the 7I92. ( +5V to PC817 module IN+ 7I92 output to
PC817 module IN-  and active low output )

Is there some other issue with reverse in the hal file
( like PWM connections if you have spindle speed control )

Ismacr63 wrote:

The LED on the PC817 module lights up when REV is on, but the spindle doesn't reverse.

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.

Do i understand correctly, you have a BOB attached to Mesa, and then from BOB to PC817?
That seems redundant as you already have the GND's wired together, so might want to get rid of the PC817 as it is not isolating anything.
Is there any resistor on the input side of the PC817?
There must be one, probably a 47-100 ohm should work.
also, might want to try the pull down version, so the pin 9 to the other input of PC817, and the input that was on pin 9 to +5V. This might also require inverting the pin in hal.

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.