Lichuan 4 axis stepper need help-

More
9 months 6 days ago #341969 by Hakan
From what I can see, different modes can live side by side in the cia402 component without problem.
They already do today. Different pins, yes. For example PV needs two accelerations and a speed pin.
Homing, probing etc their own set of pins. And possibly some small piece of logic, like "at-speed" indication.
And then handle the switching of modes with the position feedback, a bit optimistic this can be done in a general way.
The following user(s) said Thank You: rodw, NWE

Please Log in or Create an account to join the conversation.

More
9 months 2 days ago #342190 by rodw
Well, I made a start and at least have some pins displaying (see attached text file). Still so much to do after a full day on this!

Not sure if this is final but the states should look like
Code:
// CiA 402 states typedef enum {     STATE_NOT_READY_TO_SWITCH_ON,     STATE_SWITCH_ON_INHIBITED,     STATE_READY_TO_SWITCH_ON,     STATE_SWITCHED_ON,     STATE_OPERATION_ENABLED,     STATE_QUICK_STOP_ACTIVE,     STATE_FAULT_REACTION_ACTIVE,     STATE_FAULT,     STATE_HOMING } DriveState;

I need to make sure everything is seperated into readall and writeall functions.
We rtapi_malloc structured data storage when we loadrt so I hope that will work.

The statusword structure looks something like this so the bit fields are mapped overthe status word
Code:
// CiA 402 Statusword union typedef union { hal_u32_t raw; struct { unsigned char ready_to_switch_on :1; // 0 unsigned char switched_on :1; // 1 unsigned char operation_enabled :1; // 2 unsigned char faulted :1; // 3 unsigned char voltage_enabled :1; // 4 unsigned char quick_stop :1; // 5 unsigned char switch_on_inhibited :1; // 6 unsigned char warning :1; // 7 unsigned char manufacturer_specific1 :1; // 8 unsigned char remote_cmd :1; // 9 unsigned char target_reached :1; // 10 unsigned char internal_limit_active :1; // 11 unsigned char opmode_specific1 :1; // 12 (homing attained / target reached) unsigned char opmode_specific2 :1; // 13 (homing error) unsigned char manufacturer_specific2 :2; // 14-15 } bits; } StatusWord;

When I get a bit further, I'll share via github

Please Log in or Create an account to join the conversation.

More
9 months 2 days ago - 9 months 2 days ago #342191 by rodw
Ooops no attachment
 

File Attachment:

File Name: pins_2026-01-30-2.txt
File Size:1.8 KB
Last edit: 9 months 2 days ago by rodw.

Please Log in or Create an account to join the conversation.

More
9 months 2 days ago - 9 months 2 days ago #342213 by Hakan
FWIW, I thought is was nice that pins are named stat_* in Donomik's version.

My mind was into naming pins after the mode they are used in. Problem being there are overlaps.
For example there are many velocities: Homing velocity fast, homing velocity slow, PV velocity,
CSP velocity, CSV velocity, PP velocity, all using different PDOs, except CSP and CSV velocity which is the same PDO.
I would guess also Probe velocity, probably several versions.

On the other hand, it would be a bit convoluted for the user to use .csp-commanded-velocity when they already selected csp mode and see it as natural to use .commanded-velocity.


 
Last edit: 9 months 2 days ago by Hakan.

Please Log in or Create an account to join the conversation.

More
9 months 1 day ago #342230 by rodw
I've totally rewritten it anyway. I was able to move the state machine into a seperate procedure which has substantially streamlined the code. Now I just have to get it to compile image missing /media/kunena/emoticons/shocked.png

A lot of that does not need to be in the component because you are setting the pin externally. But we may need to scale or otherwise calculate data for them in which case they need to pass through the component. Get the basics first....

write all becomes something like
Code:
FUNCTION(writeall) { // Restart sequence on rising edge of enable if (enable && !data.prev_enable) data.control.raw = 0x0000; data.prev_enable = enable; if (enable) { int drive_ready = runCiA402StateMachine(&__comp_inst); if (drive_ready) { if (homing) { opmode_out = 6; // Homing Mode // Bit 4 starts homing; check for errors before commanding if (!data.status.bits.op_error) data.control.bits.op_specific = 1; } else { opmode_out = (s8)default_opmode; data.control.bits.op_specific = 0; // Clear Bit 4 // Normal Motion drive_target_position = (s32)(target_position * pos_scale); drive_target_velocity = (s32)(target_velocity * vel_scale); } } } else { data.control.raw = 0x0006; // Shutdown / Disable Voltage } controlword_out = data.control.raw; }
 
homing feedback is in the read command

Please Log in or Create an account to join the conversation.

More
8 months 4 weeks ago #342358 by rodw
Bear with me on this project.  multi axis slaves need to be managed from a single instance so the current cia402.comp will only service the first motor on the slave. I have spent a lot of time writing a new component for cia402 drives and I finally was able to try it on a drive and get movement today but it  was only on the first drive just like the current component. Now I know what I am doing I need to clean up all my debugging code and then refactor it using an array of drives in a single component. I was hoping to use a personality on the component to define the array count but not 100% sure how to set that up to define the pin array.

Its all very promising though!
The following user(s) said Thank You: NWE

Please Log in or Create an account to join the conversation.

Time to create page: 0.571 seconds
Powered by Kunena Forum