SnapAmp encoder connections (single-ended)
I'm new to CNC and the Kflop/SnapAmp, but competent at programming and comfortable with digital-level electronics. I purchased a rather early (2005) Industrial Hobbies square-column mill that has been sitting unfinished, but had the mechanicals 90% complete, and with an electronics package (PS, Gecko 320s, old Campbell Designs BOB), but I've decided to switch to Kflop/SnapAmp rather than add a SmoothStepper to the BOB, because I want to really understand the tuning, rather than just chase an oscilloscope trace with a tiny screwdriver on a trimpot inside a cabinet where I can't see what I'm doing.
Can someone (Tom?) confirm something for me regarding connecting my single-ended HEDS encoders to the SnapAmp?
Does it matter which encoder inputs I connect them to? Since they are single-ended, would it matter if I wanted to connect to the single-ended encoder inputs on the Kflop's JP7?
If I connect to the SnapAmp, do I just leave the other differential input from each encoder channel floating? I thought I read on this forum that the encoder inputs have pull-ups for that reason.
Is there any performance difference between connecting the limit switches to the SnapAmp vs. to the Kflop directly? That is, are the limit switches read with any less latency if they are connected to the Kflop? I understand that the SnapAmp is connected via the Aux connector and the Kflop basically polls it at about 11kHz. Are the inputs that are on-board the Kflop scanned any more quickly than this? I guess the only reason this would matter would be to determine how best to perform the homing routine, but I'm curious.
Thanks,
Dave
Re: SnapAmp encoder connections (single-ended)
Hi Dave,
Quote:
Can someone (Tom?) confirm something for me regarding connecting my single-ended HEDS encoders to the SnapAmp?
Does it matter which encoder inputs I connect them to? Since they are single-ended, would it matter if I wanted to connect to the single-ended encoder inputs on the Kflop's JP7?
That would be one possibility of where to connect them. The JP7 KFLOP inputs are very high impedance with no termination. So you might want to add some termination resistance in the 150ohm range (or higher resistance if the encoders can't drive that heavy of a load). Or encoder inputs 0-3 can be multiplexed over to KFLOP JP6 (see the MuxEncoders.c example) which have 150ohm termination resistors on KFLOP. JP6 are 3.3V inputs and will be damaged if driven hard above 3.85V but I have never encountered a 5V encoder that will do this. See also:
Dynomotion Motion Control Boards for CNC Manufacturing and Robotics Applications
Quote:
If I connect to the SnapAmp, do I just leave the other differential input from each encoder channel floating? I thought I read on this forum that the encoder inputs have pull-ups for that reason.
No you can not connect single ended encoders to the differential inputs and just leave the other input floating. See also:
Dynomotion Motion Control Boards for CNC Manufacturing and Robotics Applications
Quote:
Is there any performance difference between connecting the limit switches to the SnapAmp vs. to the Kflop directly? That is, are the limit switches read with any less latency if they are connected to the Kflop? I understand that the SnapAmp is connected via the Aux connector and the Kflop basically polls it at about 11kHz. Are the inputs that are on-board the Kflop scanned any more quickly than this? I guess the only reason this would matter would be to determine how best to perform the homing routine, but I'm curious.
On-board KFLOP I/O is faster. For example a User Program might sample them at MHz rates. However KFLOP still only samples Limit Inputs once per Servo Sample (90us). The SnapAmp Differential/Opto/GPIO Inputs are only read once every 4 Servo Sample times (every 360us - 16 of the 64 bits sampled every 90us). This is usually amply fast enough for Limit Switches. The 12V Opto Isolated Inputs on SnapAmp are intended to be used as Limit Inputs as they will offer more noise immunity and avoid coupling limit wiring noise into the KFLOP.
HTH
Regards
Re: SnapAmp encoder connections (single-ended)
Quote:
Originally Posted by
TomKerekes
That would be one possibility of where to connect them. The JP7 KFLOP inputs are very high impedance with no termination. So you might want to add some termination resistance in the 150ohm range (or higher resistance if the encoders can't drive that heavy of a load). Or encoder inputs 0-3 can be multiplexed over to KFLOP JP6 (see the MuxEncoders.c example) which have 150ohm termination resistors on KFLOP. JP6 are 3.3V inputs and will be damaged if driven hard above 3.85V but I have never encountered a 5V encoder that will do this. See also:
Dynomotion Motion Control Boards for CNC Manufacturing and Robotics Applications
Ah, this makes sense, thanks. I doubt my encoders can drive 150 ohms but I'm sure something's better than nothing, even if it's 1k or 2k. I can scope the outputs with different terminating resistors and see what it looks like. Fortunately my encoder cables are shielded, FWIW.
Oops, of course, my bad. I didn't know that US Digital made add-on differential drivers that just plug into the encoder. I suspect those won't fit in my encoder housings, but that's a very useful note you made on that FAQ page, thanks. At any rate I have options.
Quote:
On-board KFLOP I/O is faster. For example a User Program might sample them at MHz rates. However KFLOP still only samples Limit Inputs once per Servo Sample (90us). The SnapAmp Differential/Opto/GPIO Inputs are only read once every 4 Servo Sample times (every 360us - 16 of the 64 bits sampled every 90us). This is usually amply fast enough for Limit Switches. The 12V Opto Isolated Inputs on SnapAmp are intended to be used as Limit Inputs as they will offer more noise immunity and avoid coupling limit wiring noise into the KFLOP.
Very good to know. My optical limits are claimed to be accurate and repeatable to 0.0002" (well, we'll see), so I was imagining how to write the homing routine to take advantage of this. I'll have to experiment. It sounds like the best way to do it will be to go "fast" in (the fastest safe speed to drive into the limits while allowing a controlled stop before hitting the hard stop) and then slow out (slow enough that the encoders are counting slower than 11kHz if connected to Kflop, or 2.7kHz if connected to SnapAmp, so we don't miss a count when we come off the limit). In my case with 20k steps/inch I think that means the out speed must be below about 30ipm for limits connected to Kflop or about 8ipm for SnapAmp. Still plenty fast for the less than 1/4" travel out of the limit.
But then, I just noticed that HomeMM_V8.c in the distribution appears to be a fairly sophisticated homing routine that might do all of this, as well as move into the limits in all axes at once to save time. I should not reinvent the wheel, so I'll study that code.
Thanks for the very quick reply!
Cheers,
Dave
Re: SnapAmp encoder connections (single-ended)
Hi Dave,
Quote:
Very good to know. My optical limits are claimed to be accurate and repeatable to 0.0002" (well, we'll see), so I was imagining how to write the homing routine to take advantage of this. I'll have to experiment. It sounds like the best way to do it will be to go "fast" in (the fastest safe speed to drive into the limits while allowing a controlled stop before hitting the hard stop) and then slow out (slow enough that the encoders are counting slower than 11kHz if connected to Kflop, or 2.7kHz if connected to SnapAmp, so we don't miss a count when we come off the limit). In my case with 20k steps/inch I think that means the out speed must be below about 30ipm for limits connected to Kflop or about 8ipm for SnapAmp. Still plenty fast for the less than 1/4" travel out of the limit.
Some minor corrections: The encoders in KFLOP or SnapAmp both update Position in KFLOP every 90us. It is the Home Input connection to KFLOP or SnapAmp Inputs that would make a difference. Also Homing is normally performed in software in a User Program. With one User Thread running it would execute every 2 Servo Samples (every 180us). See:
KMotion/KFlop Multi-tasking
If you really need 90us software response you can setup a User Callback but that may be not worth the extra complexity.
HTH
Regards
Re: SnapAmp encoder connections (single-ended)
Thanks for the clarification, Tom.
And by the way, you sure ship fast. I ordered at 1pm on Monday and got the gear by lunch time on Wednesday. Thanks!
Cheers,
Dave
Re: SnapAmp encoder connections (single-ended)
I've wired up most of a break-out board on a proto-board for JP7 to connect to my encoders, limit switches, and a level converter to send RS232 to the modbus input on my VFD.
I was looking at what termination resisters to use, per your suggestion. I have HEDS-9100 sensors in US Digital E2 housings. I have read comments elsewhere that the HEDS encoders have very limited drive. These encoders may well be marginal for CNC work, especially the single-ended versions, but I gather they are quite popular with the hobby and conversion guys.
There is a (rather snarky, IMHO) application note for the Gecko G320X that recommends pull-UPS to get the encoder output above the 4V minimum input that the G320X requires. That seems like poor design to expect 4V logic high out of a 5V encoder, but it got me thinking about the output drivers in the encoders and whether I should be trying to make them sink rather than source.
The HEDS-9100 module datasheet is at: Avago Technologies
It's not long, and the electrical portion is all on page 4. When I read the datasheet it seems to say that the encoder can source 1mA and sink 5mA. Actually those are the "absolute maximum ratings". It does seem to note that they recommend a 3.3k pull-up (presumably to 5V) and the fall time specification was tested with an 11k pull-up. I'm no professional EE but it looks to me like these devices want to sink against a pull-up instead of driving a load.
Tom, what's the minimum voltage for logic high on IO0-IO7 (encoder 0-3 inputs on Kflop JP7)? Is it 2.0V? If the encoder can only source 1mA and we need to get above 2V, I can't use less than 2k ohms for the termination, which seems weak.
What do you think about a 500-ohm pull-up to VDD33? If the encoder can sink 5mA and has to pull the input to 0.8V for logic low, that seems like the proper pull-up value, but even 1k pull-up seems better than 2k pull-down. I just feel odd pulling a nominally 5V device's output "up" to 3.3V, and I don't want to do anything unsafe with the Kflop.
Or for that matter, since these are the 5V-tolerant encoder input pins, I guess I could pull up to VDD5 with 1k (since the BOB is 90% wired that would save me some work). Maybe that's the safest option.
Thanks,
Dave
Re: SnapAmp encoder connections (single-ended)
Hi Dave,
The VIH minimum for the KFLOP inputs is 2.0V. I'd suggest a 680ohm pull up to 3.3V. That would keep the required current under 5ma to go all the way to 0V. I think the line ringing/damping should be the same regardless of if the termination goes to GND or 3.3V. Pulling up to +5V might not be a good idea as that may cause 1~2ma of clamping current in the KFLOP input which may bleed to an adjacent pin because of the way the Xilinx FPGA is constructed. Probably would still work if the adjacent pin was driven properly but I'd prefer you use the 3.3V if possible to avoid the issue.
There are 3rd party encoder cable drivers that you might consider that would supply more current drive as either single ended or differential signals. USDigital.com is one vendor:
US Digital | Products
Regards
Re: SnapAmp encoder connections (single-ended)
Thanks for your time, Tom, you're the best. I'll try pulling up to 3.3V with 680 ohms.
I'd prefer to use a differential driver right at the encoders like you suggest, and may eventually do that and just run directly to the SnapAmp inputs, but as it stands I can't even fit the neat little USDigital driver inside my encoder covers and I'll have to make new covers or spacers before I can go that route. The encoders are mounted to the screws, not the servos, and are far too exposed to run them without the covers.
Re: SnapAmp encoder connections (single-ended)
680 ohms to 3.3v seems to be the ticket. If I get a chance to take my scope out there I'll post some traces of the encoder signal quality.
Thanks!
3 Attachment(s)
Re: SnapAmp encoder connections (single-ended)
Mostly for any other novices else following this, or people who have HEDS encoders, here are the scope traces.
With only the Kflop powered (no power to the SnapAmp, turning axis by hand) the traces are beautiful. With 680 Ohms to 3.3V, the encoder pulls low to about 280mV, which is just fine:
Attachment 287652
Once I power up the SnapAmp and enable the axes, there's quite a bit of noise:
Attachment 287654
I didn't notice any lost or extra steps, but then, I think the only way I can test for that is to run some G-code with quite a few moves and then use a dial test indicator to see if it returns to exactly the same spot.
Here is the setup including the BOB I hobbled up. I'll eventually make a permanent interconnect board using polarized Molex KK connectors for everything (could even design it to stack above the Kflop), but I wanted to be able to easily reconfigure the inputs and as you can see I made a little makeshift solderliess breadboard area for trying different terminations on the encoder lines:
Attachment 287666
Sorry, my scope probes make it kind of hard to see. The tan board is an old Archer (Radio Shack) proto board with the same trace pattern as a breadboard. I cut the traces between the dual-row header in the lower right.
There might be a ground loop through the USB cable and the computer, because my DC supply grounds are currently set up to be grounded to chassis, which is grounded at the AC main ground (and eventually to AC common). Maybe I should change that and isolate the DC grounds coming out of the DC supplies? On the far left in the photo is a 5V 1.5A/12V 1.5A linear supply that I got with the mill, and I'll hook that up to the Kflop and move the jumper to isolate the USB input. If that ends up reducing the noise I'll post that here.
However, the shields in my encoder cables are not yet hooked up, and the extra length in the cables at this point is coiled up in my chip tray (about 4-5 coils each axis) and the motor leads do run right over the top, so there is surely some induced noise there.
At any rate X and Y are moving at 100ipm (the servos' max RPM won't do much more than that) and by playing with feed-forward values in the servo loop, it looks like position error (at least, at the encoder) is within one ten-thousandth even at 50 in/s^2 acceleration. This is using less than 6 amps peak current. I'm happy with that. Using KMOTION.EXE to do the tuning is miles better than trying to tune Geckos. You actually feel like you have enough information to do the job (more than I know how to use, certainly... this will teach me how to use a Bode plot).
Re: SnapAmp encoder connections (single-ended)
Separate posting so Tom doesn't have to dig through the above post to notice:
My nominally 65V 12.5A servo power supply is putting out about 76-77V as reported by the SnapAmp on the Analog screen in KMOTION.EXE. On deceleration of an axis, especially the heavy spindle, the voltage climbs and I'm concerned it will go above 80V.
Is there anything I should/can do to increase the safety margin for the SnapAmp? For instance, enabling the voltage clamp at 80V?
i.e. in my init.c, add:
Code:
WriteSnapAmp( SNAP0+SNAP_SUPPLY_CLAMP0, SNAP_CONVERT_VOLTS_TO_ADC(80.0) );
WriteSnapAmp( SNAP0+SNAP_SUPPLY_CLAMP_ENA0,1);
WriteSnapAmp( SNAP0+SNAP_SUPPLY_CLAMP1, SNAP_CONVERT_VOLTS_TO_ADC(80.0) );
WriteSnapAmp( SNAP0+SNAP_SUPPLY_CLAMP_ENA1, 1);
Edit: I found your example at the bottom of:
Using SnapAmp
That example uses 90V as the clamp, so I presume that the SnapAmp can handle momentary excursions above 80V. Unless you have a different recommendation I'll apply the 90V clamp like shown on the above link.
Thanks!
Dave
Re: SnapAmp encoder connections (single-ended)
Hi Dave,
Regarding encoder signals: It would be interesting to connect the shields to KFLOP GND to see how much difference it makes. Cranking up the time scale to ~ 1us might allow seeing what the noise glitches really look like and if they are at the 30KHz SnapAmp Switching frequency. Sounds like you might have some GND loop issues. It would expect it to be better to have the Motor Supply isolated from Earth GND. Removing the USB power Jumper will not isolate the DC GND from the PC.
Sometime scopes lie and pick up noise from earth GND and the probes themselves to show noise that really isn't there. As a sanity check I sometimes clip the probe to GND to see how much noise is still shown.
Regarding Voltage Clamp: Yes set the clamping a few volts over your maximum supply voltage. Take care never to set the clamping below the supply voltage. All SnapAmp parts are rated for 100V or more but we spec 80V max for margin. BTW you can plot Supply Voltage on the Step Response Screen to observe what the Supply does during a move.
Regards
5 Attachment(s)
Re: SnapAmp encoder connections (single-ended)
Quote:
Originally Posted by
TomKerekes
Cranking up the time scale to ~ 1us might allow seeing what the noise glitches really look like and if they are at the 30KHz SnapAmp Switching frequency.
I assume you meant 10us? At 1us/div, 30kHz is wider than the screen. Here's the result at 5us which gets two spikes on the screen:
http://www.cnczone.com/forums/attach...d=287754&stc=1
The spikes are periodic and look similar to each other (sorry I didn't snap a photo at 10us/div which would have shown that) and the period between them measures at around 31us/32kHz, and what I'll call "ringing" continues for about 5-10us after the initial spike. This seems to confirm your suspicion that noise at the PWM frequency is getting into the encoder lines:
http://www.cnczone.com/forums/attach...d=287756&stc=1
Here are close-ups of those two spikes (captured at the previous V/div so the resolution isn't all it could be, but I think you get the picture):
http://www.cnczone.com/forums/attach...d=287758&stc=1http://www.cnczone.com/forums/attach...d=287760&stc=1
Quote:
Regarding encoder signals: It would be interesting to connect the shields to KFLOP GND to see how much difference it makes.
Quote:
Sounds like you might have some GND loop issues. It would expect it to be better to have the Motor Supply isolated from Earth GND.
I bet you're right. When I have a chance, I'll isolate the DC grounds, and connect the encoder cable shields to Kflop GND, and I'll report the results here. I think you've given me quite enough help to get me straightened out for a while (thanks!), but I think this thread will eventually be quite helpful for other newcomers, which is why I'm going into so much detail, and I'll keep documenting this stuff here. BTW you are welcome to use any of these images that you find useful in any help file/FAQ/whatever, and if there are any particular shots you'd like me to collect I'd be happy to.
Quote:
Sometime scopes lie and pick up noise from earth GND and the probes themselves to show noise that really isn't there. As a sanity check I sometimes clip the probe to GND to see how much noise is still shown.
Hmm. I dutifully attempt to connect the probe ground properly and have always assumed that would control noise enough to give me reasonable traces. At any rate, I clipped channel 2's probe tip to the same ground point I'm using for both channels' ground clip, and the channel 2 (blue) trace on the previous image is the result. You can see just the tiniest spike, just above the scope's sampling resolution. So there is a tiny bit of noise being induced into the probes some way other than through the tip, but not enough to change our conclusions I don't think.
Quote:
BTW you can plot Supply Voltage on the Step Response Screen to observe what the Supply does during a move.
Yes, I love that awesome feature! Here's a 15000 count (3/4") move of my Z axis downwards and back up, which drives the supply voltage up by about 2V when the spindle stops at the bottom of the stroke. You can also see some other interesting things like how much harder the servo has to work to lift it back up, and that about 2/3 of the voltage rise on stopping is due to gravity, and about 1/3 due to inertia (though I suppose those things are even more easily seen by looking at the output or current graphs):
http://www.cnczone.com/forums/attach...d=287762&stc=1
Re: SnapAmp encoder connections (single-ended)
Hi Dave,
Interesting plots thanks for sharing.
Your scope setup indeed seems clean.
Noise spikes seem wider than I would have expected. I was thinking they might be 10's of nanoseconds which is why I thought you might need 1us scale or faster. It might be showing us both the PWM on and off transitions.
Regards
2 Attachment(s)
Re: SnapAmp encoder connections (single-ended)
OK, here's the update.
Isolating the DC ground made no difference. This surprised me. I double-checked that I hadn't missed any grounds and I didn't. No change at all. I suppose that could mean that I missed the actual ground loop, but I don't see where it could be.
However, connecting the encoder shield did help quite a bit. Here's a trace before connecting the shield:
Attachment 287790
Note that the vertical scale is half what it was in the previous photos (500mV/div instead of 1V/div) which makes the noise look twice as bad, but it's really the same.
After connecting the shield, the noise was quite significantly reduced (not eliminated, but reduced to a point that makes me much more comfortable):
Attachment 287792
I didn't think the shield would help because the amplitude and shape of the noise didn't change at all when I moved the encoder and motor lines relative to each other.
For those who wonder whether it's worth the time to shield the encoder lines, these two photos should be a helpful data point. In this machine it reduced the noise from about 2.75V peak-to-peak down to about 0.5V ptp. More importantly, now the voltage when the encoder reads high doesn't drop below 3V. Without the shield, the noise would cause the voltage to dip as low as 1.25V for nanoseconds every 32kHz.
One other thing: when I first reported the noise, I said it appeared when the axes were enabled. That's not true. The noise is completely absent from the time the Kflop/SnapAmp are powered up until the point that the init.c file is run, enabling the axes. After that, the noise is present even if I disable all of the axes. I presume the SnapAmp, once initialized, does not shut down when the axes are disabled (just reduces outputs to zero).
The amplitude of the noise only changes slightly with the level of output to the servo. That is, when the SnapAmp is moving the X servo, the amplitude of the noise is barely stronger (visually, ~10%) than when the axis is disabled. Pragmatically I'm happy about that, because I think it means that encoder cable shielding alone will be adequate for this machine.
Cheers and thanks for your help!
Dave
(Now I just have to figure out why the SnapAmp disables itself -- lights actually go out -- every time the Mach3 plugin is loaded.)
Re: SnapAmp encoder connections (single-ended)
Quote:
Originally Posted by
dgiller
(Now I just have to figure out why the SnapAmp disables itself -- lights actually go out -- every time the Mach3 plugin is loaded.)
Again for other newbies' benefit:
If you (like me) had previously configured Mach3 to use the parallel port, then you probably have a bunch of outputs configured in the "Ports and Pins" dialog. It would appear that one or more of these confused the Kflop/SnapAmp. After I disabled them by setting the port number to 0, the SnapAmp works fine in Mach3.
BTW, if you just disable the outputs by turning the green check mark into a red cross, Mach will think you don't have X, Y, or Z axes and you won't be able to configure the motor parameters (counts per inch and acceleration) in the Motor Tuning dialog. So you at least need outputs configured for those axes you actually have. Just configure them for non-existant ports/pins (like port 0 pin 0).
