I am a mechanical engineering graduate student, my masters' thesis is the design, construction, and control of a linear delta robot. My question to you guys is whether a phidget is capable of switching digital outputs on/off at a frequency high enough to drive a stepper motor at high speeds while microstepping.
My current setup is using c# to do the kinematics and trajectory generation, then I send 6 polynomial coefficients (the motors follow 5th order polynomial trajectories) and a time for each motor to an arduino due via serial communication. The arduino has a motor control algorithm that moves the motors using pololu stepper motor drivers. I feel like this approach is not very robust, and would love to cut the arduino out of the picture altogether.
I have read that serial communication is not suitable for doing precisely timed communication in the realm of microsecond intervals. If phidgets use a similar communication to control the inputs/outputs of the phidget I can see it not working. Is this the case? Or do phidgets use a communication protocol more likened to a parallel port? I considered using a parallel port but didn't want to risk frying my expensive gaming computer by messing up the electrical isolation circuit I would need to build.
Are you saying that each stepper motor needs to execute something more complex than the usual trapezoidal velocity profile or is that sufficient? If it is, then any off-the-shelf microstepping controller board, eg Phidgets 1067, would suffice.
Bob-666 wrote:Are you saying that each stepper motor needs to execute something more complex than the usual trapezoidal velocity profile or is that sufficient? If it is, then any off-the-shelf microstepping controller board, eg Phidgets 1067, would suffice.
Bob, part of my thesis is making the stepper motors follow 5th order polynomial trajectories from angle A to angle B, this allows for continuous acceleration and eliminates infinite jerk spikes in theory. Sadly it is much more complicated than the trapezoidal velocity profiles.
Ok, one way is to build your own circuit controlled via the parallel port - any cheap ancient second-hand PC will do - preferably one that runs DOS which you can program with Visual Basic for Dos, Turbo-Pascal etc. Multi-tasking operating systems like Windows are not so good for real time control as they tend to go off and do their own thing when they feel like it which can mess up your microsecond timing. Take a look at the datasheets for the NJU39610 and the NJM3771 which you can control via the parallel port buffered with 74HCT14. You don't need opto-isolation if you have a 5V supply for the logic chips and a separate, say 36V, supply for the motors - the switching spikes will be on the high-voltage supply. But ... how many motors do you need to simultaneously control? You don't have many port pins although if you find yourself one or two short you can also control the RTS and CTS pins on the serial port on microsecond scales. You just need to convert the voltage levels to TTL using eg a MAX202.
I don't think you can rely on anything connected via any kind of serial bus for this kind of control - the timing is too uncertain.
Thanks for the advice Bob. Here is a video I made of the current method of control I am using if you are interested.
It works great for 'joint' moves, but for linear moves where I have to do lots of small joint moves continuously flowing into each other it is getting difficult. A friend told me about phidgets and I thought it may present a more robust solution instead of having to deal with serial communication. I think some of the problems I am having may be due to the serial buffer overflowing on the arduino's input side, not sure, but I would love to eliminate the serial communication altogether.
Using a parallel port is definitely something I considered, but sadly I have too much time invested in this control method to change now unless it proves impossible to do what I need it to do. For future projects I would definitely like to use the parallel port's IO pins. I would need 8 outputs (3 steppers to move the end effector, one motor to extrude filament if I turn it into a 3d printer, with a step and direction output for each motor). Then some inputs for end stops and encoders (3 optical end stops for the linear axes, and an inductive proximity sensor mounted to the end effector for auto-bed leveling, and 6 inputs for the quadrature encoders) which makes 10 inputs but I can probably do the encoder reading with a microcontroller, they are just for verification purposes for my thesis.
Good video - it would be interesting to compare the performance using polynomial moves versus trapezoidal moves to see if you can quantify the advantage. Ideally, though, you need to have a realistic load on the motor in terms of friction and inertia - it's behaviour may be quite different when heavily loaded. A common error is to de-energize the motor phases immediately on completion of the move - the inertia of the load will cause the motor to free-wheel several steps past the intended stop position. You need a delay!
I write the stepper controller firmware at Phidgets. I really liked your video, I'd really like to implement this type of 5th order control with Phidgets - unfortunately right now we only support simple 3rd order control, and there is no way for you to directly control the stepper yourself - we take acceleration/velocity/position and calculate the steps in firmware. I'm hoping to implement better control in our next controller, but it's a tradeoff between better control algorithm and max supported velocity, as well as which micro we decide to use. Also, our boards only support one stepper, so coordination is a problem for multiple steppers. At any rate, I'd love to read your thesis!
You may want to look at our USB encoder boards - I think they'd be perfect for you.
I'm glad you liked the video! I will definitely try to remember to post a link to my thesis once it is 100% done. I just got the linear moves to work along with circular moves with an adjustable parameter for (moves/cm). Those are the only two types of moves I will be doing since it is the majority of what is found in Gcodes. I will be attaching my motors to the robot to verify that it is all working as intended very soon. Before I do that though I need to make a zeroing protocol which should be easy.
I'm glad you liked the video! I will definitely try to remember to post a link to my thesis once it is 100% done. I just got the linear moves to work along with circular moves with an adjustable parameter for (moves/cm). Those are the only two types of moves I will be doing since it is the majority of what is found in Gcodes. I will be attaching my motors to the robot to verify that it is all working as intended very soon. Before I do that though I need to make a zeroing protocol which should be easy.
Thanks for the reply!
Is your thesis done yet Soronemus? Would love to read more about it.
Last edited by SilvaMouse on Fri Feb 14, 2020 3:05 am, edited 4 times in total.
SilvaMouse wrote:
Is your thesis done yet Soronemus? Would love to read more about it.
It is not completely done yet, but I have made a ton of progress. I have the wiring done, the motors attached, and the controls are done. The motion is very smooth. I am in the process of testing the resolution/repeatability of the robot. Below is a small album of the robot setup I am using. It is hard to see but there are optical encoders directly coupled to each of the motors that I will use to collect data from the motors. I will use numerical differentiation on that data to obtain the angular velocity, acceleration, and jerk to verify that there are no infinite jerk spikes (which the 5th order polynomial motion is supposed to prevent). http://imgur.com/a/KcEBL
I am scheduled to defend my thesis within the next 2-3 months. I will try to remember to post a link to the actual document after I have successfully defended. Thank you for your interest in it!
