Advanced Search

Axemas,
Having been away from nativecam use for a few months, I came in to the shop yesterday morning ready to wrestle with the bodged-together version that Bogdanthegeek and Giovanni made possible last year. Super delighted to find the results of your work, installed and up and running very easily on a new machine (morbidelli author 503), in use within an hour or so. Thank you so, so much! As others have said, hopefully FernV is well and just no longer interested in his fantastic project; it's great to see it alive again, and ready to try out on the lathe too, and maybe the side drills on the morbidelli (if I ever get round to wiring those back in).

So far I find one unexpected behaviour, to do with the way part alignment responds to Workpiece axis align value:
I have workpiece of 150x150x2400, Y align = centre, and a rectangular array also with Y align = centre. Workpiece Y coord = 0, array Y coord = 0.
I would expect the array to show up at Y=0, but it appears instead at Y=-75; changing the array's Y axis align value (top/centre/bottom) does not change the array position.

Y axis copies was 1 for this behaviour. Playing around just now, changing that number made the array reset and appear as expected.

A minor oddity in an exceptionally welcome piece of software. Thank you again!

hello..i have a problem with my plasma cutter..I am using a 7I76E. The plasma torch goes down, senses the work piece, rises to the pierce height , fires the torch up but does not maintain the arc to cutting flame. Because of this, it then goes off instead of moving to cutting height and cutting flame.

I have this gang type lathe with live tools and I am thinking about converting it to LinuxCNC 
in the future:
www.smartlathe.com/products/sl-36

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.