Hi Brad,
It just isn't clear to me that is the way to go. BTW I just looked up exactly how Galil works and their basic homing example involves a 10 line "program" involving cryptic mnemonics with one blocking call. It has fixed wired inputs so that does eliminate specifying the IO bit. After reversal it stops "instantly" at both the home switch and the index pulse which seems like it could miss-step unless it goes really really slow. It looks like all other communication would be locked out while the communication is blocked in the AM (Done??) command. So I don't see how that is the model technique we want to emulate. They do allow multiple axes to home at once which I suppose would be good for slaved homing. BTW this is of their
Accera controller which is over 10X the price of KFLOP and 125us loops times (slower that KFLOP and only possible then by loading "fast" firmware that disables lots of features like filters)...
Also there are some technical issues which makes it difficult to implement in KFLOP.without adding something like another Thread to the system. The calculations to do a normal blended 3rd-order deceleration profile are a bit too long to do within the servo interrupt. Adding another cpu thread (much like a User thread) could do it but that would steal cpu time from the existing system thread and the other user threads. Besides slowing those down it would make things indeterminate. Currently things are simple, clean, and very predictable.
I was thinking to meet you half way. Write a simple parametrized home.c routine however you wish. After we find 2 systems where it handles the homing requirements we will hard code that function into KFLOP and add a script command to launch a User Thread to execute it. Then instead of your App having to code Load/Execute "Home.c" it can just issue a script command "DoHome" and the result will be exactly the same.
Some have stated that 98% of users do a simple home from a switch. That sure hasn't been my experience. More like 2% :} Often initialization and homing is one of the more complex issues with a system. And rather than focus on the 2% that have trivial homing anyway that we can provide for them, I'd really rather make the more complicated cases easier. I'm not sure this is going to help my case, but Carl comes to mind. He has a basic xyz router but the requirements he ended up with were:
- 3 z stepper axis as spindles
- shared home and single limit for Z
- needs to move fast to save time, then repeat slower
- must move out of switch if already in the switch
- must move inside switch some amount, zero, enable switch as limit
- reversed slaved axis X0 and X1
- X0, X1, Y are brushless motors
- phase find bushless motors from index pulses
- must phase find X0 X1 together
- X0 X1 independent/simultaneous home to square
- limits used to square, then re-enabled as limits
- first fast then slow
- programmable squaring offset then slaved
This all resulted in 670 lines of C code (with comments and progress printouts). It would be great if these type of options were readily available to pick and choose from.
But I keep thinking this is like trying to allow someone to write programs without knowing how to code. Like a graphical system where one plugs together modules. But those never seem to work in the real world...
More thinking out loud...
Regards
TK
