Homing sequence inside .comp

More
5 years 5 months ago #208907 by gcardinal

andypugh wrote: ... Just have the .comp respond to a "home-now" pin then when that pin changes from low to high it can output a constant homing velocity output until it sees {whatever tells it that it is homed}


New attempt - I did the following:
HAL
- Signal for when X or Z axis are homing (axis-homing)
- Signal for when X and Z axis are homed (axis-homed)

.comp
- Monitor change to axis-homing and invalidate previous ATC homing state
- Monitor change to axis-homed, wait a few seconds and start ATC homing

Next step would be:
- Link pin for limit switch on ATC
- Write code to move ATC to the limit switch, latch, back-it off.
- etc.

Does it looks like the right path?

PS: Sorry for me being thickheaded and thank you for helping.

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

More
5 years 5 months ago - 5 years 5 months ago #208908 by andypugh
A few pointers:

1) A realtime comp is passed a variable "fperiod" which is the time elapsed since it last ran.

2) Realtime comps are often best written as a state-machine. This just means that there is a variable that determines the current state, and various rules for changing state.

A (very) simple state-machine with a timeout might look like this:
Code:
component state; param r signed state = 0; pin in bit trigger; ;; static bool old_trigger = 0; static float timer; switch (state){ case 0: // waiting if (trigger && trigger != old_trigger){ timer = 1.2; state = 1; } break; case 1: // doing thing timer -= fperiod; if (timer <= 0){ state = 0; } break; default: rtapi_print_msg(RTAPI_MSG_ERR, "Ooops!"); } old_trigger = trigger

Take a look at the HAL "carousel" component for an example if this structure in the context of a toolchanger (and including homing)
Last edit: 5 years 5 months ago by andypugh.
The following user(s) said Thank You: gcardinal

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

More
5 years 5 months ago #209207 by gcardinal

andypugh wrote: A few pointers:
1) A realtime comp is passed a variable "fperiod" which is the time elapsed since it last ran.
2) Realtime comps are often best written as a state-machine. This just means that there is a variable that determines the current state, and various rules for changing state.
...


Thank you for the help and feedback. I have switched to state-machine and implemented delay using fperiod. Also homing sequence is now working and locking tool in nearest position.

There just a few issues left:
- I would like to slow down during home latching and turret locking sequence. I can't figure out how to move at different speeds.
- Since after homing and locking the tool, actual position of the turret and logical are out of sync (due to lost steps when moving into locking position and hitting "stop"). Is it okay to take value of .stepgen.02.position-fb as an starting point / zero and move tools from it?

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

More
5 years 5 months ago #209229 by andypugh
I can think of a couple of ways to alter the speed. You could add a pin that connects to the stepgen velocity limit pin, and change the value of that.

More conventional would be to increment the position command at a fixed velocity:

Something like:
Code:
case HOMING_LATCH: if (atc_limit) { position_cmd += 1; } else { if (position_cmd < target_pos){ position_cmd += latch_velocity * fperiod; } else { position_cmd = target_pos; if (delay == false) { timer = LOCKING_DELAY; delay = true; } event = HOMING_FINISH; } } break;
The following user(s) said Thank You: gcardinal

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

More
5 years 5 months ago #210058 by gcardinal

andypugh wrote: ...
More conventional would be to increment the position command at a fixed velocity:
...


Thank you again! I now have a working version that changes tools on command and correct tool is pre-set in .ini file
Code:
[HALUI] MDI_COMMAND = M61 Q2 MDI_COMMAND = G43 H2

There is a few issues left:
- Homing and locking needs to be slowed down.
- If tool is not set in tool table - there is an error that causes next tool move to be in wrong direction. So .comp needs to be aware of that condition (tool is missing in the tool table) and don't do anything.
- When ATC is changing tools and triggers limit switch - its a good opportunity to verify physical and virtual position of ATC.
- Need to implement some kind of GUI in order to display current active tool.

I will continue working on the component and will be posting back when its all done. Latest version in git.

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

Time to create page: 0.054 seconds
Powered by Kunena Forum