I’ve got another thread going asking about going native, which I think means/includes pinvoke (http://www.tinyclr.com/forum/1/2419/#/1/msg24067).
as for components, I thought about pushing 1’s and 0’s into a shift register for each axis and then clocking them all out simultaneously. Haven’t done exactly that sort of thing before, so we’ll see what I run into.
Funny, I have been working on a board last few days for same issue (first one). Fez loop or native is not solution as you still have interupts that will jitter the motor steps. Ultimately, would still need some interupts to handle Stop, change, etc. Send 200 steps, but need a way to cancel those if Stop. So it starts to get hairy all kind of ways. My thought was off-loading to a PIC to control N steppers and use simple UART serial commands (FwdLeft200, Stop, TurnLeft90, etc). Using a 40pin PIC18f877 as need almost all those pins for just 2 controllers if you want full control of all the logic pins on the stepper driver. I am close to ordering via BatchPCB (just need last review before upload). Need to still work on the PIC software. If you want, you can help me beta and test. You can then order the same board yourself from BatchPCB and solder your parts on.
Here is pcb layout so far. Using two Pololu steppers drivers on sockets here. The Pololu is very nice and has the updated 16th step mode chip.
This will do 2 steppers independently. For a 4x4, I was thinking a second, simplier, board (no pic) that just mounts the 2 additial rear drivers and steps, DIR, Mode, Enable, Sleep pins are just hardwired/jumpered to the master. Both Lefts wheels would do same thing, same with rights. Would act like a track drive. But this should be ok for what I am looking for. Using this method, could add 6 or 8 drives if needed. Any thoughts?
I have a couple questions for experts:
Can I just direct TTL from the fez to the EUART pins on the PIC without having to add RS232 level chip on the board?
Both controller have onboard 5v (or 3v) reg out supply. So right now, I am just tying both 5V (and 5v-gnd) to same 5v bus which powers the stepper logic and the PIC and power LED indicator. Should this be ok having both hooked up to same bus? The 18f877 has dual vdd and vss pins (not sure why). I tie bus to all 4.
A MikroC sample shows using 8Mhz crystal in short UART sample. Does not say why 8Mhz over something else. Is this what I want?
tia
Thanks for the offer on the beta. Your board looks good. I’m needing 4 independent axes. Step and direction, probably enable, x4, so the board probably won’t work for me. Also not sure about UART in my case.
I did some calcs and I think I can live with up to 400us differential between pulse trains that should be sync’d. As long as it doesn’t go much more than that… Also, my final step freq will be ~15kHz, but I’ll no doubt want to go faster in the future.
Now all I need it time to work on it.
Can’t help on the expert Q’s, sorry.
When you say “4 independent axes”. Do you mean Left front may go forward and Left Rear backward? Or forward at different speeds? I guess I am confused. As your question was moving 4 at same time - no?
You could also do a simple board and just tie together the steps for the motors that will be in sync and then drive them both from 1 fez pin. I would do a PCB regardless, even if just a breakout. Too many dang wires to control a stepper 2x/4x. But then again, not understanding your 4-axes requirement. Maybe describe your movement needs a bit more. tia
Yes, each axis would be able to go a different speed and direction. Note that “speed” may also mean “zero” for one or more axis at times. Here’s an example of what I was hoping to send via outputCompare (but mine would probably be on the order or a few thousand elements each):
buf1 = {0 1 0 1 0 1 0 1 0 1 0 1 0} fast move, no ramp
buf2 = {0 0 0 1 1 1 0 0 0 1 1 1 0} slow move
buf3 = {0 0 0 0 0 0 0 0 0 0 0 0 0} idle
buf4 = {0 0 1 1 0 1 0 1 0 1 1 0 0} speed ramp up/down
The DIR and EN signals would be sent via digital outs (4 x 2 = 8 pins) as they are not time-critical.
By sync’d, I mean/meant that the pulse trains start at the same time, such that the moves are coordinated. That does not mean that they would be identical. What you were describing, with wheels going the same dir and speed, I would call one wheel a slaved axis. Two stepper drivers, but only one independent axis.
Sorry, also meant to point out in my example that the “ramp” case precludes the use of PWM as the pulsetrain changes (the “duty cycle” is not constant for the entire buf4).
Still not shure what kind of vehical/robot needs this? You making a center pivot Loader?
Not sure we are in sync on my controller. Both L and R steppers can move different speeds and directions independent of each other. If you need rear wheel drive, you would tie-in to respective front-left or front-right master. I could move all 4 independent speed and dir, but currently can’t see the need for that level of complication yet. I am assuming track style will work for 90% case, but maybe not. I may hit that need after getting farther into the project.
“Sorry, also meant to point out in my example that the “ramp” case precludes the use of PWM as the pulsetrain changes (the “duty cycle” is not constant for the entire buf4).”
That is another reason I am going down the co-processor route. For that reason, as well as others, you are almost forced to do a timing loop and control pulses yourself. But, unless you are doing nothing else on your fez (i.e. no threads or sensor interupts), you will get jerky 20ms (or more) pauses between thread switches. A kinda robot version of tourettes.
Your other option would be to forget about steppers and go with a dc motor controller that can set direction and speed with a relative Voltage level based on a center reference voltage (i.e. 0 is full reverse, 3.3 is full forward, 1.65v is stop). Then it is a simple matter of setting analog voltage levels on 4 pins from your fez. Add feedback encoders as needed for degree rotation feedback.
never said vehicle.
this was my first router. it has problems. planning the second one 'cause it’s easier to start over than fix this’n. thought I might try driving it with panda to see how it goes. really should have RT; do have a panda.
ah. cool. I think I have that same router (in a box). 3HP and starts with a T I think? Now I understand why you kept talking about 4 axis. doh.
In that case. I think you should be able to a PID loop and set your 4 step pins with a fez register in one shot. Next turn of crank may be different pins set. The stepper only “sees” low-to-high transision anyway, so you have more room for slight timing changes then what I first assumed.
You already set Steps at end of loop, so even if you hit a GC switch or something, motors not going to move another step in any direction until you loop again and tell them to. So it ~should be tight control with your PID loop. Direction is set before next Steps, so you should be ok there also (don’t need registers for DIR pins as just need to set them before next step). Seen gus talk about using fez registers, but have not tried them on fez yet. I am going to do same kind of deal with Ports on the PIC so assume it may be similar. PID loop setting Step registers.
I think your problem space got simplier (no pwm or native needed) . Does this make sense?
makes sense, sort of.
I don’t think PID applies in open-loop stepper control but I get what you’re saying. I was planning linear vel ramps, with smooth transition to final vel, if needed.
good call on the leading-edge-only transitions at the driver. hadn’t remembered that.
You’re right, the stepper position will be “known” even if GC, etc. but I also worry about instantaneous velocity change. Steppers like regular pulses, particularly when they’re at higher speed (and lower torque). I’ll just have to try it.
I’ve played with registers to try and speed up analog reads for a different project (made no difference, btw). I’m sure I could figure out how to bit-bang a nibble at a time. This feels “inelegant” but I think it’s a consequence of trying to use the wrong - or not enough - hardware.
I think I’m to the point that I need to hook up wires and write some quick proof-of-concept code. I probably won’t be able to get to it until next weekend…
@ whyitsmoking
I say PID, but mean what ever arm control logic your using. Forgot what that is called.
Using registers, in my mind, is for setting the 4 step outputs at ~same time. Not for gain in speed as such. But to reduce 4 sync calls to 1 output call. Sort of an atomic output operation. All needed steps high or low.
Stepper pulse time still has some grey area for me. For example, in full step mode, you need to delay 1ms anyway after each step or will overdrive the controller. 1ms is least allowed delay with with MF Thread.Sleep(…) (or zero). I guess you could also do some spin-wait for less. So stepper naturally stops at next step anyway so not sure how much fluid motion can be built up. I think fluid is only “perceived” from the short start/stop steps. AFAICT, you can’t “Nail” the next step in perfect timing to last because of outside factors such as load and voltage. I think the best you can do is not be too greedy and not overwrite the last step (e.g. motor buzzes in place).
Contrast, 16th step mode. You don’t need the 1ms delay between steps (only 200us min for the driver) in free air. But what happens under load? What if it takes 900us to do the step under load, but you drive another step at 600us? There is no feedback loop that a step is actually 100% complete so you we have to assume the worst case? It would be cool if the driver would cache at least 1 or 2 steps. Maybe it does and have not read about it.
Not done any real cnc myself. But not sure it is ~inelegant as they all use varition on this same theme using a control loop. As you discovered, pwm does not make sense in this context as you need individual step control and pwm does not really add value there.
Another reason why I think native may not actually help much here. Could be wrong. Because you have to delay anyway at the bottom of the loop (before next step). So you can run light speed, but still have to wait. Would have to test, but that sounds like a lot of effort. I would keep it to 1 thread, use registers for step outs, and see where that goes.
Look forward to your project. Can I get a sign? 
Sorry, but when I saw this the first thing that went through my mind was Bill Engvall, “heere’s your sign…”.
Thing’s not really accurate enough right now to give a decent looking sign. I’ve been driving it via the parallel port (Mach3) under XP. I want to try it via Panda to see if the stalling/jitter I get is due to driving or mechanical. Regardless, I’m going to rebuild it with bigger motors, better alignment, and a better x-axis setup – and all the stuff I learned not to do from the first one. Not sure when I’ll be getting to that…
I’ll let you know when it’s closer to being done. I’m sure we can get a sign to you somehow.
Jitter or a ticking sound when using the parallel port with Mach three is a good sign that you have a really poor step pulse stream being generated. Have you run the Drivertest.exe to see what the graph looks like? If you have a scope take a took at the step pulse waveform as well.
By default Mach 3 produces very, very short step pulses and if you have any issues with interrupt latency quite often the pulses wind of so narrow that the stepper drive will not ‘see’ it. One quick thing to try is to set ‘Sherline 1/2 pulse’ mode to on (first page of Ports&Pins). This really stretches out the step pulses and helps many systems out.
My general advice for Mach is to ditch using the parallel port and use a SmoothStepper: http://www.soigeneris.com/SmoothStepper-details.aspx (my website). It generates the step pulses via an FPGA and produces a very smooth step pulse stream.
Also, you will get better performance by sizing the stepper motors to the application. Just bolting on bigger motors generally does not really help. Using a good quality stepper drive, with a good power supply, at the proper voltage for the stepper motors, and you will have a good running system. These items have to be picked as a set to match the application for best results.
Cool. Hadn’t run across that one yet. It costs more than my whole first machine, but there is definitely something to be said for having at least some of the right components… 
I’ve played with the pulse length settings, and it helps to a point, but I had not tried Sherline mode.
@ whysitsmoking
Cool. Hey, I need some 90deg stepper mounts. Not really want to make at this point. Any sources? Think 31mm on-center square pattern with center hole for drive shaft area.
No, sorry. I roll all my own.
Hello
You cannot synchronize multiple OutputCompare’s.
But you can use RLP code to write data to multiple digital pins at the same time.
The time shift between two pins is 2 µs on FEZ domino.
You can download my RLP project with a C# demo project here:
http://www.tinyclr.com/forum/17/6104/#/1/msg58325
It writes up to 8 digital pins synchronously.
Very easy to use in C#.
Elmü