Serial TTL signal generation to control motor driver via DAQ

[maeosu]

Hello,

With LabVIEW, I'm trying to communicate to a stepper motor driver that reads TTL Serial protocol. The driver that I am using has preinstalled commands decoded from of a TTL signal (fake example: HALT is command int178 == 0b10110010 and TTL signal is high/low square signal representing 0b10110010 + parity and other odds and ends) and I need to be able to generate this TTL signal based on an integer input. I will probably write a Python script connected to a Python node to manage the command input, but the actual translation, generation, and transmittance of a TTL signal I am clueless on. I think I will use DAQmx to transmit to a digital output pin. 

The hardware is a PCIe-6343 card with a DAQ and I plan to use 1 digital output pin (with 5V and GND pin) to transmit TTL signal to the motor controller.

I apologize I am not well versed in LabVIEW or the graphical language; but I have spent several days reading forums/help and asking around with no luck so I have resorted to posting a question. 

If anyone has any guidance on how to generate these TTL signals it would be much appreciated!

Thanks

[RTSLVU]

---

@maeosu wrote:

Hello,

(fake example: HALT is command int178 == 0b10110010 and TTL signal is high/low square signal representing 0b10110010 + parity and other odds and ends)

Other odds and ends like Start and Stop bits, parity. Basically a serial data protocol

Why not just use a USB serial to TTL converter?

[maeosu]

Hello,

Thanks for your reply.

We could as a last resort, but we are trying to fully utilize our DAQ/PCIe-card for all of our I/O peripherals of our system and not the computer. 

[RTSLVU]

I guess it's time versus money

You can spend time figuring out how to bit bang the serial protocol out one pin of a DIO port...

Or for about $40 you could buy an adapter and be communicating with your device using VISA like any other device on a serial port...

[maeosu]

Money is not an issue with this project, but time is - so if you are telling me that there is no LabVIEW block/tool to convert integer --> TTL signal and that I'd have to build it all from scratch, then that is useful information to me!

Building our system off the DAQ is of high preference for this project, but if it's not practical...it's not practical.

I spent a fair amount of time digging around in the VISA toolbox, only to find it'll only talk to a port, which wasn't useful until now. 

Thanks 

[crossrulz]

If you have the PCIe slots available, I would go with something like a Startech PEX2S953LP (2 serial ports) and then a IC232TTL to adapt to your TTL device.  I am not a fan of USB, so I would prefer having the dedicated card for this.  Then it is just simple writing to the port using VISA.

EDIT: Since this is a NI site, I should probably also link to their options.

[maeosu]

Thank you for your feedback and links! We may have another slot, I will have to check.

May I ask why you are not a fan of USB?

[cbutcher]

I'd guess PCIe falls out less often 😉

[crossrulz]

If you are not careful, Windows has a "power saving feature" where it will just turn off your USB hubs.  This has caused issues.  Also, if you plug into a different port, it may show up as a different COM port, causing issues with your application.  Back in the day, it seemed like only 1/2 of the USB-RS232 adapters would work.  Those issues seem to have alleviated over the years, but I still have a bad taste in my mouth.  I have never had an issue using a PCI(e) or PXI(e) RS-232 card.

[RTSLVU]

---

@crossrulz wrote:

  I have never had an issue using a PCI(e) or PXI(e) RS-232 card.

---

I used to say that until I had a number of StarTech PCIE serial port cards just stop working. Honestly I nave never  figured it out but the ports would just "disappear" no error or anything, just no longer exist. This happened in multiple computers in the lab but never happened to some and they are still in use today.

But since Windows7 FTDI USB to Serial  adapters have been rock solid and Windows remembers their UUID so they always get the same Com port when plugged in.