Advanced Search

I've actually got bigger problems here now.  I am not getting proper communication between linuxcnc's lcec driver and the ethercat slave.

I don't have any errors on startup but if I toggle an output from halshow, the light comes on in halshow but the actual state does not change on the device. This worked previously but on a different config. eg, this no longer toggles the physical outputs.


I can set the same output pins on and off using the ethercat upload and download commands.
I Stripped out all of the SDO commands for modbus but it is still not working. Not sure how to resolve this issue.

Ahh, now I have it working again. dmesg showed an error loading my xml but Linuxcnc was silent on this. I missed something! Now I will add stuff back in slowly.

I don't really have anything here like a USB to 485 adapter to test vfd comms with and there are no status lights.

What I have worked out uploading registers is that I have a timeout error and the error count increments all the time

I think I have worked out all the XML syntax and settings.

@ruediger123

The restriction is the corner itself. A sharp corner is a mathematical direction discontinuity. The velocity vector must change by ~191 mm/s across a 45° turn. With a 1ms cycle time, respecting 50 m/s³ jerk would require spreading that change over ~3800 cycles, during which the machine travels nearly a meter. No feed rate fixes this, the problem is geometric.

The only mathematically correct solution within your parameters is for the planner to detect that no valid cornering speed exists that satisfies the jerk limit given the available segment geometry, and fall back to a full stop at the corner. That is exactly G61.1 behavior.

This is actually a valid point and potentially a missing feature: the junction velocity calculation should be jerk-aware, and when the jerk-constrained cornering speed rounds down to zero, the planner should stop rather than arrive too fast and spike. Currently it may only be acceleration-aware at the junction, which allows a non-zero entry speed that looks acceptable to the acceleration limit but still violates jerk because the ramp does not fit in the available geometry.

The practical workaround in the meantime is either G61.1 explicitly, or a P tolerance of several mm to give the planner room for a proper S-curve through the corner. P0.01 is geometrically equivalent to sharp.

This is not really an XML problem.

The XML is just a configuration layer for PDO mapping.

What you actually need to understand is:

PDO structure (Rx/Tx)
Sync managers
How lcec interprets the XML

A good workflow is:

1 - Use ethercat pdos to discover the device
2 - Reproduce exactly the same structure in XML
3 - Only then refine HAL mapping

Quick question:

Your device reports:
PDO entry 0x6000:01, 16 bit

But in your XML you configured:
bitLen="32"

What do you think happens if the device expects 16 bits,
but the master tries to map 32 bits?

Also, check this:

<pdo idx="0x1a00,">
<pdoEntry idx="0x6000,">

Notice anything unusual there?

I would suggest:
- match the bit length exactly (16)
- remove the trailing commas
- start with a minimal mapping (no complexEntry)

Once it reaches OP, then split into bits.

No you do/did not, i have plenty such stories where i missed things in front of me, that is normal and utterly human, especially when we deal with complicated stuff and put all our attention sometimes in the wrong place!
The thing i am consistently working on and having issues with, is get better at explaining things and get over the "typing" lazynes.

And to reverse any axis/joint, just add - sign in front of the SCALE value for that joint.
But beware, that will also change the homing direction for that joint so HOME_search/latch/final_VELOCITY might also need a - sign in front of their respective values.

So I tried physically swapping the Y2 dir- and dir+ , but it didn't help the end result any


If swapping DIR+ and DIR- (on the drive _or_ 7I76 end only) does not change the Y2 direction,
There is a hardware or wiring issue.

Hi Tommylight

Thank you for the info, much appreciated

You were correct on both counts. 
I didn't want to ask how you knew one of the Y motors is reversed,  without first trying to figure it out myself first.

As you can see from the attachment text doc below,  I tried a few things, but I was not able to figure it out.

What (which fields) caught your eye ?

My Y1 jogs in the correct direction, my Y2 jogs in the opposite direction. 
Many thanks

***********************************
The long version of what I tried ....

The config attached is my last known good which Homes all three axis (with a but ...)

(X zero, and Y zero, is front bottom left - when standing in front of the machine , looking at it). 


But ...


if I move the Y axis gantry as a whole , after homing completes, (jogging just 1mm at a time)

the Y1 gantry motor goes 1mm towards the rear of the machine (which is correct)

and

the Y2 gantry motor goes 1mm towards the front of the machine (which is incorrect)

So it just ends up racking the machine in slow motion


I tried very many settings, and eventually lost my way, and ended up relentlessly crashing the Y2 side of the machine


I don't know what settings to try to get the Y2 motor to Jog correctly, without affecting the Homing

***************************************************************

All motors are wired in exactly the same order, from the drivers to the motors

So I tried physically swapping the Y2 dir- and dir+ , but it didn't help the end result any

**************************************************************

I also made a config of just X and Y1 and Y2 (no Z) and NOT as a gantry (but as independent motors)
and was therefore able to bypass gantry Homing (as without homing, the gantry won't move)
each motor ran in the correct direction, when independently jogging a few mm at a time 
(testing that there wasn't a physical problem with either the wiring or with the motor drivers) 

**************************************************************

I also found that by making another test config using mesaCT, a with and without, a y2 reverse direction tick, it added two fields
STEP_INVERT= False
DIR_INVERT = True
I only tried the "DIR_INVERT = True" on the Y2 joint which didn't help either

**************************************************************

To recap

I have been able to make the homing of all three axis Home (although the signs still make no sense to me)

I have been able to test the x and y1 and y2 motors working in their correct jogging direction (when not in a gantry mode, and not homed)

I am unable to make the machine do BOTH things (Home AND then Jog the Y axis gantry with Y1 and Y2 in sync together, so gantry doesn't rack)

**************************************************************


My "process" for testing positive and negative homing values 

Start by setting the Y axis gantry of the machine to 25mm (width of a ruler) , so both Y1 and Y2 motors 
Have the same distance to travel, from their respective proximity sensors to the steel it senses against (so the Y axis gantry always starts from a known position)
Set all the signs of the values to positive on both y1 and y2 joints (in Geany)
Switch the power on to machine , and mesa cards
Wait for notification that ethernet is connected 
Launch LinuxCNC
Select the config
Estop off, machine on
Home all
Watch which direction the gantry begins to move on both Y1 (left side) and Y2 (right side)
If it goes in the wrong direction , change the sign  
Repeat for each of the 4 iterations of homing one axis

The attached file , Homes as the photos show. (But Y2 jogs in the opposite direction)

Just incase there is some random element to this somewhere , I re-ran this Homing configuration successfully, ten times in a row. 

**************************************************************





 

@grandixximo
The machine is congigured with a 1ms servo cycle, the speed with 15 m/min, the acceleration with 5 m/s² and the jerk with 50 m/s³ so nothing unusual for servo axes.
P64 P0.01 Q0.0 is also not unusual.
In my opinion, the limits for jerk, acceleration and speed should not be exceeded so that the behavior of the machine is predictable.
The unusual thing from my point of view is that MAX_LINEAR_JERK and MAX_JERK are different.
If there are restrictions on certain parameters, please let me know so that I can take them into account in my tests.

I really needed a slap upside the head!

Blame this on me, despite me writing this a few posts back:

tommylight wrote:

You still have the:
....

I was convinced the comp issue is separate from this one, and was wondering why are you testing the comp since it is not mentioned in the error report...
Should have raised a flag ... or a smoke signal, wold have probably been more useful.

Oh. Doh!!!!!

Thanks a lot. I was so focused on the comp, I missed the obvious.

Hmm.  I didn't check on a sim, just my real hardware.

My backplot jumps when I do the switchkins switch, but no amount of fiddling could get the hardware X-axis to move when I had velocity set to zero.

I understand.

I would have chosen that approach.
First, set up a system where the module runs, and then read the communication data.
I think it’s very consistent of you not to use Windows.
Respect.
As far as I know, there are also system managers that run on Linux.
Would that be an option?

Aciera wrote:

Are looking at the right file? The error is in 'turret.hal' (ie the hal file) NOT 'turret.comp' (the component)

Yes, this.

I went through all the recommended steps on the forum with the exception of clearing the disk of Windows and partitioning the whole disk as MBR and then reinstalling windows.