How do you hook up a handwheel encoder to an ACC-14E?

I'm not sure if this is the place to ask this, but I'm trying to use the card for encoder feedback for a hand wheel. I'm having trouble finding samples of how to hook up the wiring. Thanks. Casey

Casey, Acc-14E is a TTL level I/O card. What type of an output does your encoder have? If it is a normal quadrature output, then you have better luck using an input on an ACC-24E2 series or and handwheel port on ACC-5E.

[quote='Sina' pid='627' dateline='1281692744'] Casey, Acc-14E is a TTL level I/O card. What type of an output does your encoder have? If it is a normal quadrature output, then you have better luck using an input on an ACC-24E2 series or and handwheel port on ACC-5E. [/quote] Sina, Attached is a manual for the handwheel I'm considering using. I'm currently using an ACC-24E2A and all 4 encoder inputs are being used for motor position feedback. I don't have room for any more cards. I'm using one of the connectors to hook up to an OPTO22 board. I was hoping I could use the remaining connector to get my handwheel input.

Casey: From the manual, it looks like you should be able to connect the A and B inputs to 14E inputs without any problem. (I wouldn't bother with the A/ and B/ lines.) The issue for you now is that you have to perform the "quadrature decode" in software (the ACC-24 boards have hardware circuits in their ASIC to do this). I would write a PLCC 0 or an "Open Servo" for a spare "motor" to do this. Fundamentally, you will need 4 variables, which I will call NewA, NewB (from the present cycle), OldA, and OldB (from the last cycle). If NewA is different from OldA, you will count up or down depending on the state of B; If NewB is different from OldB, you will count up or down depending on the state of A. Good luck!

Do you have to tie the A/ and B/ to common? Right now I am not getting a signal from A and B.

cfordyce, You should leave the A/ and B/ floating or connect them to 2 extra inputs on ACC-14E, however, as curtwilson mentioned it is easier not to use them. Also, make sure the GND connected to your handwheel is the same GND on ACC-14E. Regards,

No, you do not connect the You could also consider converting the quad output to either an Up/Dn counter or Pulse & Direction signal. Either of these options are very easy to implement in code but the PLC has to execute fast enough not to miss counts or you're hosed. With a 100ppr handwheel this may not be an issue, or in many cases with a handwheel it may not be an issue to miss a few counts anyway. Another option if there is a PC in the system is to use a 'quad to USB' converter. In this case you bring the counts into the PC and pass the info to PMAC for response. No counts lost, no plc response issues; just feed the count commands to a motion program or plc - you may need to do some filtering/conditioning, etc to prevent the 'herkyjerkies'. http://www.beiied.com/electronics.html Check out the USB converters and the "Broadcaster Module". The broadcaster has an option to output Up/Dn or Pulse/Dir from a quadrature encoder.

No, you do not connect the You could also consider converting the quad output to either an Up/Dn counter or Pulse & Direction signal. Either of these options are very easy to implement in code but the PLC has to execute fast enough not to miss counts or you're hosed. With a 100ppr handwheel this may not be an issue, or in many cases with a handwheel it may not be an issue to miss a few counts anyway. Another option if there is a PC in the system is to use a 'quad to USB' converter. In this case you bring the counts into the PC and pass the info to PMAC for response. No counts lost, no plc response issues; just feed the count commands to a motion program or plc - you may need to do some filtering/conditioning, etc to prevent the 'herkyjerkies'. http://www.beiied.com/electronics.html Check out the USB converters and the "Broadcaster Module". The broadcaster has an option to output Up/Dn or Pulse/Dir from a quadrature encoder.

Should I have any problems having an OPTO22 IDC5 module capture the A and B signals?

Judging from the the OPTO22 page, I think I may need to get a couple IDC5B (4-16V) or IDC5D (2.5-28V) modules. I only have IDC5 modules. That would explain why I wasn't receiving a signal. The IDC5 has an input voltage range of 10-32.

If the encoder signals are 0-5V then a direct connection to the ACC-14 will give the fastest response. This would eliminate the added complexity of an Opto22 board.

Well, all of my I/O is already wired to the opto board, it is just a ribbon cable from the ACC-14E With a 100ppr hand wheel, if I used the IDC5B (.05ms switching capability) I could get 200 rev/sec of the hand wheel. If I used the IDC5D (1ms switching capability) I could get 10 rev/sec of the hand wheel. If my hand wheel Vout is over 4V, I'm going to try the IDC5B and see what that does.

cfordyce, Can you list all the accessories you have on your UMAC rack? Maybe there is a simpler solution for you.

Turbo PMAC (only has serial and aux serial connectors) ACC-54E (USB1.1 only. Not functioning, looking for replacement) ACC-24E2A (x,y,z,spindle. All closed loop, using encoder inputs) ACC-36E (using for feedrate, spindle, rapid speed override) ACC-14E (2x 24ch OPTO22 attached by ribbon cable) I have a 2 channel ACC-24E that I could put in the space used by the ACC-54E. I eventually want to incorporate this card anyways because I have another axis I want to add. I could use the encoder input on one of those channels. I am using this in a CNC application. The unit is communicating with the PC via a vb.net UI. It does not require DPRAM to operate, but I wouldn't mind having it so I can get my axis position refresh rate up. Right now it is set at 500ms, but I think it mostly has to do with the vb program. What is the best communication time I could expect over serial?

cfordyce, I strongly recommend using the extra ACC-24E2 card that you have and use one of the encoder inputs for your handwheel since it would be a whole lot easier than all the suggestions above. Also, the serial communication can be efficient depending on how much data is being passed through. Although the speed is not comparable with Ethernet or USB communication, it is still useful.