- Posts: 22
- Thank you received: 0
Homing sequence inside .comp
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.
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:
Take a look at the HAL "carousel" component for an example if this structure in the context of a toolchanger (and including homing)
Please Log in or Create an account to join the conversation.
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 conventional would be to increment the position command at a fixed velocity:
Something like:
Please Log in or Create an account to join the conversation.
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
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.