Advanced Search

I haven't read deeply in to lcec component, but I wonder if there's a polling process to check for changes.  I'd be interested if drives change state on some parameter if they're disconnected.

@spumco I think the underlying functionality (i won't say issue, as it's probably intended functionality) of drv-fault is in the lcec component, as once the drives unplugged, the drive can't really report a problem, and they don't trigger an error if communication is lost, they simply go idle.
I'm assuming the drv-fault only triggers once the drive actually errors, but I've not found an easy way to get the drives to fault yet, although i did just think about how to do it without risking blowing one up.

@rodw that's the kind of thing that I'm aiming for.

If you really wanted to lock it down you could try using the comp component with your lcec.0.slaves-responding against the expected number of slaves (eg set with setp). Then if you used estop-latch to manage your estop (which you should be using anyway), you could add an additional estop-latch in your estop chain so the machine could not be enabled until all slaves report in.

mwc wrote:

Just had a quick look, and drive error isn't currently collected, but I can add that.
I already have a line to check amp-fault-in, but having just checked in Halshow, drv-fault remains unchanged if I unplug the drives.

Maybe see if there's a drive parameter you can adjust which defines what the drive considers a 'fault.'

I would think that a drive would default to 'faulted' if it gets unplugged, but who knows what drive programmers think?  It could be that the default setting is 'fault' only gets asserted if there's an internal following error or under/over volt condition.

spumco wrote:

<snip>

 

 

Just had a quick look, and drive error isn't currently collected, but I can add that.
I already have a line to check amp-fault-in, but having just checked in Halshow, drv-fault remains unchanged if I unplug the drives.

Thanks for that.
it was that kind of general overview I was looking for, as the look/colours can always be changed.

MonoKrom looks interesting, but I spent a bit time today playing with Qtplasmac, as it comes installed.
Even if I don't use it, it's given me some insight into background configuration, as I managed to get my EtherCAT drives configured into it fairly easily.

I might attempt to install it over the next few days, and see how it compares.

I've just spent some time buried in the linuxcnc-ethercat documentation, and I think I have a solution to my first question.

lcec.0.slaves-responding gives the current number of slaves active, so I'm guessing I can use that via Classic Ladder to monitor for any major failings, and trigger a suitable warning?
I should be able to pull the basic Error status from the controlword, but it'd be nice to pull the actual error code without having to open a cabinet to look at the drive (on the nice to have list!).

My main concern is that LinuxCNC loads up without any warning if the drives aren't powered up, or the CAT cable is unplugged, and the first that you know there is an issue, is when you try moving an axis and get a position error. I like to cover most common eventualities when retrofitting/building a machine, so a basic sanity check of all the slaves being online I think is quite essential.


Something I've found missing from the linuxcnc-ethercat documentation, is a more general overview of the XML, as although it goes into good detail on specific functions, I can't see anything about the more general function of blocks. Like why are there 4 syncMaster blocks, yet the first two are empty (and required by the Lichuan drives!)?

For example my current question is how do I configure the drive current during initialisation?
I should really write a driver* for my Lichuan CL3-E57H drives, but even looking at the drivers for other drives, I'm not sure where that setting would fit into the XML, as I can't even find an example where somebody has set the current.
I'm fairly sure it shouldn't be in the syncManager/PDO block for the 1ms updates, but where does it go?


*I'd be willing to write a driver, but it would probably need the existing Lichuan driver renamed, as from a brief look at it, there is a bit more difference than just 4x the number of axes, as the xL3 drivers have more IO, so I think for simplicity, keeping the drivers separate would provide cleaner drivers for both.

mwc wrote:

 
Is anybody reading the status from drives during operation?
I know I could connect the drive error variable to a suitable HAL pin. but is anybody also reading the error code?

 

Check your xml file - it may already have a fault status hal pin 'baked in'

And cia402.comp has a drive fault pin:
If you can unplug or power off your drive and LCNC doesn't error out immediately, your setup could use some work.  Do you have anything connected in HAL to joint.N.amp-fault-in?

It mostly comes down to personal preference.
Glade is old school, been around a long time
QT is a modern GUI development environment, commercial but available for use for free
There are two frameworks to implementing QT in LinuxCNC
QTVCP - part of the LinuxCNC core, used by QTplasmac and QTDragon
QTPYVCP - A separate project used by ProbeBasic and MonoKrom
With plasma you have 2 choices,   both use the plasmac.comp component.
QTplasmac or Monokrom.

QTPYVCP is a pretty cool environment but in my view hampered by recent changes to Python that mandates use of virtual environments to use it.
Its also not as well documented.

In my view, there is not much difference between probe basic and qtdragon, so ease of installation sent me to qtdragon when it was evolving. And I could not install Probe Basic on Debian Bullseye. Both require a 1080p monitor.

MonoKrom is an interesting beast. I've had a lot to do with the early development and am good friends with James the developer. Its far more capable than qtplasmac, including high-def style hole processing and workflow features. I also think its more touch screen friendly.

James has recently (in the last few days)  developed a Post processor for Freecad for Monokrom and qtplasmac so watch for that in future freecad releases
 

A 3 point center finder is included with the Flex GUI...
 
JT

Most drives have an error output. What happens if you monitor that? Normally you would send it to joint.n.fault-in can't remember if its NO or NC.
But what about monitoring a normal stepper drive or a Mesa card. Isn't the same risk there?

tommylight wrote:

Unless there is something fundamental that i am missing, you can not turn the saw while cutting, never ever, so "motion.interp.heading" can not be used, so why Rod?

Exactly, why I said "In your case that would be 0 degrees."

This is a LinuxCNC forum, not a general CNC forum. we should not be discussing alternative CNC environments. Personally, I chose LinuxCNC because it can handle whatever I throw at it, accepting the learning curve because as I built different machines, I could keep using it.
With LinuxCNC, building with a parallel port gets you going with an old PC and a $10 BOB  is far superior and probably far cheaper to something like a grbl board and leaves you with an infinite upgrade path.

tuxcnc wrote:

ESP32 is 3.3V and it is too low for some drivers, but some will works.

Sorry i forgot about this, mainly because i tested several drives and all worked fine.

I'm more interested in the inner workings of the different GUIs, like why I'd choose Qtvcp vs QtPyVcp vs GladeVCP, as the looks/layout can always be changed.

From somebody who's just started to look at LinuxCNC in detail, it just seems to be a variety of options with no clear reason why you'd pick a certain one.