TMCM-351 USB gives different reply than RS232

[jlight@exactsciences.com]

Hi,
I just received a new TMCM-351 board. When I use my custom windows 7 / dot net 4.0 (VS2010) software to send binary commands through a virtual COM port through a USB to RS232 serial adaptater connected to the TMCM-351 RS323 serial port, I have no problems and get the expected datagram responses from the board. However, if I use the virtual com port for the direct PC USB to TMCM-351 USB (COM3 in my case) , the datagram response in the NET SerialPort class input buffer is the same as the message sent. I know that the USB connection works OK for the TMCL.EXE in direct mode over the same direct USB to USB connection (COM3). Any suggestions?

[Olav Kahlbaum (TRINAMIC)]

I do not have much experience with .NET programming (the TMCL IDE (TMCL.EXE) is a native Windows program), but maybe you have configured something wrong in your communication class or you are reading the wrong buffer (or are you reading out the buffer too early?). With native Windows programs (and most probably also with .NET), the virtual COM port connection has to be configured just like a real RS232 connection.
Here is which configuration we are using with native Windows programs (like the TMCL IDE):

Code: Select all

ComHandle=CreateFile(ComName, GENERIC_READ|GENERIC_WRITE, 0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
GetCommState(ComHandle, &CommDCB);

CommDCB.BaudRate=BaudRate;
CommDCB.Parity=NOPARITY;
CommDCB.StopBits=ONESTOPBIT;
CommDCB.ByteSize=8;

CommDCB.fBinary=1;  //Binary Mode only
CommDCB.fParity=0;
CommDCB.fOutxCtsFlow=0;
CommDCB.fOutxDsrFlow=0;
CommDCB.fDtrControl=0;
CommDCB.fDsrSensitivity=0;
CommDCB.fTXContinueOnXoff=0;
CommDCB.fOutX=0;
CommDCB.fInX=0;
CommDCB.fErrorChar=0;
CommDCB.fNull=0;
CommDCB.fRtsControl=0;  //or RTS_CONTROL_TOGGLE when using RS485 adaptors
CommDCB.fAbortOnError=0;

SetCommState(ComHandle, &CommDCB);

//Set buffer size
SetupComm(ComHandle, 100, 100);

//Set up timeout values (very important, as otherwise the program will be very slow)
GetCommTimeouts(ComHandle, &CommTimeouts);

CommTimeouts.ReadIntervalTimeout=MAXDWORD;
CommTimeouts.ReadTotalTimeoutMultiplier=0;
CommTimeouts.ReadTotalTimeoutConstant=0;

SetCommTimeouts(ComHandle, &CommTimeouts);


With this configuration, the normal WriteFile() and ReadFile() functions can be used. The TMCL-IDE uses an extra thread for the serial port communication (real RS232 and also virtual COM port) to speed up communication.

[jlight@exactsciences.com]

Thanks for the reply. I reviewed the code that you sent, but not all of these settings seem to be available to .NET SerialPort object, except the ones that are non-zero, which have been set as described. So seems to be issue with how .NET interacts with the direct USB serial driver? Using this configuration
COM3 - direct PC USB to USB port on TMCM-351using Trinamic supplied USB cable
COM6 - PC USB to USB to RS232 serial adapter to RS232 port on TMCM-351.

.NET code works with COM6 but with COM3 it copies the sent datagram into the read buffer instead of sending it to board.

If anyone knows of a workaround to this problem, please let me know.

[troycumbo]

I'm seeing the same behavior with a pure RS-232 connection on COM1 to a TMCM 351. It just spits back the command string. Nothing I've tweaked among the SerialPort members has had any effect. The TMCL-IDE works fine, but for whatever reason the controller seems to be incompatible with the C# SerialPort class.

[Olav Kahlbaum (TRINAMIC)]

There must be some wrong setting in the C# SerialPort class (maybe some loopback option switched on?), so that maybe the TMCM-351 does not even get the data, but you are getting back all data you are sending.
The TMCM-351 (or any other controller) itself does not "know" what kind of program or operating system is on the other side. It just sees the data it gets and then reacts on this.

[troycumbo]

I was able to get past this by working in binary instead of ASCII. Maybe ASCII communication in C# runs into Unicode-related issues? I'm using UTF8 as the port encoding, no handshake. Seems to work correctly so far.

I use an AutoResetEvent and a lock{} block to force (I hope) synchronous and orderly communication. You can set the ReceivedBytesThreshold to 9, but I've found the DataReceivedEvent sometimes fires with 8 bytes in the receive buffer. So you may need something like this (obviously, timeout instead of risking an endless Thread.Sleep()) to get the correct reply:

Code: Select all

        private void _port_DataReceived(object sender, SerialDataReceivedEventArgs e) {
            SerialPort sp = (SerialPort)sender;
            while(sp.BytesToRead < 9){
                Thread.Sleep(100);
            }
            sp.Read(_response, 0, 9); // _response is a byte[]
            traffic_cop.Set(); // traffic_cop is an AutoResetEvent.
        }


Just remember endianness...C# [edit: under Windows] converts int32's to byte[] with the LSB first; TMCL expects the MSB first. You'll have to reverse the array to send/read the value field.

[Olav Kahlbaum (TRINAMIC)]

Thank you very much for your hints on using (virtual) serial port communication with C#. I think this will be very helpful for many other C# developers too.