Advanced Search

in master branch 2.10, the currently executing line number can be found on this pin
motion.interp.line-number
If you get the number of lines as gmoccappy does you can calculate the percent processed in real time

 

In case anyone else needs to work with HAL_HBar and HAL_VBar components in Glade, it turns out that I didn't have my hal file configured correctly for the HBar. Within Glade, there is a description the zone limits for color changes is based on 0.0 - 1.0 which is a fractional percentage of the MAX/MIN limits, not what is required for input. Hence, what ever the MAX?MIN limits are set to, zones are based on the fractional percentage of that range.

I had to remove the SCALE component and just net gmoccapy.program.progress directly to the GLADE HAL_HBar component for everything to work as expected.

Thank for all you help.

Lcvette wrote:

it sounds like the machine you built is very specific for some dedicated work you need to accomplish. the conversational i created is really geared more towards a job shop type workflow on a traditional toolroom cnc lathe. not sure it would be of much help for your automation geared setup.

 

It's more of a 'standard' gang-tool lathe with some extra capabilities. And I look forward to using your conversational features - that's one of the primary reasons I'd prefer not to build a GUI from scratch.

The side panel is certainly one place I can stick some indicator LED's.  And I suspect not many people are running LCNC, much less PB, with a sub-spindle or live-tools.

On the other hand, I'd argue that a parts counter is lathe-agnostic.  I've seen a few LCNC parts counters (usually via Ladder) grafted on to other GUI's, but nothing 'integrated' in a GUI.

Yet every commercial CNC lathe I've seen or used has a parts counter of some sort.  Tool-room, slant-bed turret, gang-tool, VTL, etc - all the controls have some way of keeping track of parts, and using the counter's parameters/values to drive bar/slug handling macros.

A part counter with references to bar-feed sub-routines can be done entirely inside G-code (incrementing parameters), but there's no (good) way to monitor the status while a run is in-progress.  A built-in parts counter makes it gravy.

I've never used anything other than integrated graphics. no need for a seperate GPU

tommylight wrote:

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.
 

 

Your understanding is correct:

Mesa 7i92 → Chinese BOB (5 V outputs) → PC817 module → DI4 of XP200 servo (24 V input).

I use the PC817 to adapt the 5 V level to the 24 V input of the servo, because the BOB cannot drive a 24 V input directly. Even though the grounds are connected together (no isolation), the optocoupler's output transistor acts as a simple NPN switch to pull DI4 to ground.

PCW wrote:

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 )
 

I tested the sinking configuration exactly as described:

+5 V from BOB → IN+ (anode) of PC817 module

IN- (cathode) → pin 9 (GPIO12, 7I92)

Output V → DI4 (XP200), G → 24 V GND

HAL: spindle-ccw → GPIO12 with invert_output true

The LED now lights up when I activate REV (M4), and turns off in FWD (M3), exactly as expected. However, the spindle still does not reverse.

Thanks again!

 

Using a bash script to start LCNC followed by the kill script works.

I've created a desktop launcher, however, I can't add it to my quick start panel. Seems to be a limitation associated with Debian 12.

Thanks again for pointing me in the right direction.,

@spumco
I think most of that could be done with the new user configs, pb lathe already has a large sidebar xz dro and you could add additional as needed. i think for the led/dro/the sidebar would be ideal. and the user main dro bottom panel is configurable already for any number of combinations.

it sounds like the machine you built is very specific for some dedicated work you need to accomplish. the conversational i created is really geared more towards a job shop type workflow on a traditional toolroom cnc lathe. not sure it would be of much help for your automation geared setup.

@susan-parker
sweet keep me posted! i think this would be right up your alley for your machine!

Yeah, I was starting to think the same, but still need to do a bit more digging regarding drivers and firmware tonight. I just built myself a new PC last year and still have the old one with a couple PCI slots... Seems like a more modern MESA setup would be Ethernet based nowadays (for my use case), but using the 5i22 would still get me going with Linuxcnc again, even though it is overkill, and many of the skills I develop would likely transfer to a more modern setup for the next project.

Thank you for reporting back.

Try the scale component (set gain to 0.01) to convert 0..100 to 0..1:
linuxcnc.org/docs/html/man/man9/scale.9.html

Dell Optiplex 790 is still usable but needs at least 4GB of RAM.
Lenovo M93 with 4000 series CPU are also good, so if this is what you can get it is better than that Optiplex.
Fujitsu from that era are also OK.

I found the culprit!

Apparently, the customized component that handles the SPI communication with the customized remora-spi firmware is not compatible with trixie.

This is the part in the code that breaks it.

The soc ranges path is different in trixie.

I modified the component so, that when the path does not exist, I just consider it as a Raspberry Pi 5 with RP1 chip, and now it works!

I know it's just a quick and dirty workaround, but works for me.

Finally, after a long wait, the boards have arrived! Now I'm looking to buy the PC to control the machine. Checking all the models you shared before, I couldn't find any of them available in my country for under $700 USD.

However, I found two options: a Dell Optiplex 790 with an i5-2400, and another refurbished PC with an i5-4400 (the seller didn't specify the exact model, just that it could be an Optiplex, HP, Lenovo, or Bangho).

Which one would recommend? Both rely on integrated graphics. Is that going to be an issue in my case? From what I've read, a dedicated GPU is usually recommended, but I'm not sure if that's only for software pulse generation or if it's recommended for hardware-assisted setups too.

Thanks in advance!

I was looking at one of my "bigger ones" and it has a measly 2kB.
About 80 000 lines of G-code. ,
A bit of 2.5D surfacing nothing really exciting.

While gmoccapy.program.progress does display the current progress of the job, it reports the value as whole percent rather that fractional percent. Unfortunately, the HBar widget requires fractional percent between 0.0 and 1.0.

Is there a way to convert the output of program.progress in the HAL file when connecting the signal or will I have to use an on_changed handler to do the conversion?