Lichuan 4 axis stepper need help-

Well, I think it follows the state diagram up to the point of operation
 

But for sure it isn't perfect. I have noticed multiple homing components around even if I don't use it myself.
Can you add support for PV (Profile Velocity) while you are at it? I made a quick fix for that.
PV is suitable for spindle mode.

You should be able to transition states manually, in halshow for example, using controlword and check statusword.
Maybe that can give a clue to why it seems so grumpy.

I gave some detailed instructions to Grok last night then slept like a baby.. I always wanted to use a C union to break out status word etc into  bits starts to make it readable.
 
 

Its just a snippet of code and not the whole picture.
But I wouldn't switch state before statusword says the drive has switched state.
It would be in some pending_switch_state perhaps.

Yes, I need to check it all. I did see previously that cia402 was not waiting for confirmation of homing or something so will watch for that....

Do you think it is even possible to make a general homing component?
The drives I have seen have numerous different homing options.
Will all of them work?

The cia402 component has no easy task.
The device runs the cia 402 state machine and the cia402 component has to figure out what state it is in. 
From that, rebuild the control word to match what you want it to do next.
You can't let the cia402 component be the master of the state machine, the device is.

I don't know much about how homing is supposed to work,
otherwise I could try to help more.
 

The issue with the original code was it was developed with a machine that homes to index so it does not work cleanly with home to sensor. The real problem  is that during device homing, Linuxcnc throws following errors because it has not commanded movement. What generally needs to happen is the position feedback is synced with commanded position so Linuxcnc is happy. This is why most working solutions also provide their own cia402.comp

Yes, I think homing can be standardized for cia402 devices and the new home comp is there now to support that. So much of homing.c becomes irrelavent with device homing so the homecomp allows control of what is needed. I've had a couple of goes at it. The first was obsoleted by a rewrite of the homecomp paradigm.

The cia402 state machine is actually very simple. very linear with the exception of error and safety steps to prior states. The flowchart here is a good resource
www.kebamerica.com/blog/comprehensive-gu...a-402-drive-profile/

Anyway, back on task. It occurred to me that I had included some standard PDO's that are not reported by Ethercat pdos. I will revisit that. 

 

The same thing happens when people switch between csp and pv modes (rotary axis to spindle motor and back),
they have problem with the rotary position feedback. Could there be a general way? Save the position, and later
create an offset to add to the position feedback. Sounds like that could work.

The point I wanted to make about cia402 state machine was that the device decides the state,
the cia402 component can only react and ask for a change of state. 
 

The cia402 component really only uses two states, disabled and op enabled, controlled by the enable pin.
Either transition to and stay in disabled mode, or transition to and stay in op enabled mode.
When in op enabled state, you can switch between the different operation modes. Anyway.

Is there no message in the syslog when you have a mismatch between pdos? I would have expected something there.
 

Yes I did get your point but glossed over it. The joint becomes enabled and that is passed to cia402 to enable the Ethercat drive. the state machine turns it on safely and  manages errors/faults
The drives measure in pulses per rev and we use pulses per mm so it converts between scales too. (I think that's right, been a long time)
Looking at the current comp github.com/dbraun1981/hal-cia402/blob/main/cia402.comp#L142 
The velocity/position mode is only set at startup (in write-all), Is there a reason for that? Could we change modes when in an idle state? (which I will have a state for) Does not seem it would matter much to the drive

I have not started yet. I wanted to publish a couple of videos first. Got my Ethercat instalation one done this morning.

38? -3 here.
What made it work?

Don't know why they don't allow switching between csp and csv.
You switch to homing mode and back, so you do switch modes on the fly.
Had a guy in here that switched modes, although he switched between two cia402 components,
one was Dominik's for CSP and one was mine for PV mode (mostly a quick hack github.com/MetalMusings/cia402pv)

Searched and found many drives that allow dynamic switching while in op-enabled.
That's not a proof it is universally allowed, at least it isn't forbidden.

The current component is quite limited in that respect. It could support CSP, CSV, PV, PP, Homing, maybe also Torque Profile mode.
The main difference is which pins are active as inputs and outputs I guess. Plus the feedback position/velocity/ferror

 

Hakan wrote:

38? -3 here.
What made it work?
 

Actually hit 41.8 deg C here today so a bit hotter. (Therefore I did not get that much done!)
I cheated and only moved the one working motor for the video oops!
I saw that: Modes can be switched while the drive is in the "Operation enabled" state
Probing could also be handy.
I'll keep you in the loop