Reading from a specific device over virtual COM

[dwilches]

The following question is copied from a user's email regarding using Ardity to connect Unity and a specific hardware device without using an Arduino in between.

Dear dwilches,

I have found your Ardity library and I found it quite interesting as I am trying to read in Unity an incremental encoder.

I was wondering if I could use your library to communicate with this specific device:
https://www.rls.si/en/e201-usb-encoder-interface-123

I am really not an expert on this and will have to trial and error a lot I guess, but I was wondering if you could give me some tips/directions to understand if I have to modify your library or I can just use it as it is.

I would really appreciate your help,

Warmest regards,

[dwilches]

Hello,
I'm glad you are interested in using Ardity.

I've checked the datasheet of the E201 and yes, it can be used with Ardity.

Ardity can connect to anything that appears in Windows as a COM port, and your datasheet says there are drivers available for this purpose. This is the relevant excerpt:

Virtual Com Port (VCP) drivers available for 32-bit and 64-bit Windows (XP, Vista, 7 and 8/8.1, 10) Linux and Mac OS X uses generic CDC drivers.

There is a section towards the end of that document titled "Installation of USB Drivers" that you should follow prior to setting up the device with Ardity. Once you can see your device as COM1, COM2, or some other COM port I recommend you try to access it with a software like PuTTY (it allows you to interactively send commands to your encoder and see the response). Here is a video I found that explains how to use PuTTY over serial ports . This video is not specific to your device, but the instructions apply nonetheless. Your datasheet says "Speed settings of the virtual serial port can be any value." so you can use the a 9600 baud rate.

Once you are able to connect to it using PuTTY, test the connection by pressing the letter "v" inside PuTTY, your datasheet says that commands prints out version information. So if you see your device's version, everything goes well.

Now, when configuring Ardity you'll need to know 3 things:

• The baud-rate: we already know 9600 works fine (use higher values if you want more speed)
• The port number: you'll find this out watching that Youtube video and testing with PuTTY.
• The record separator: your datasheet says it's 13. I got that because at the end of the output of every command (page 6 and 7) it says the output ends in "CR" and a CR (carriage return) has ASCII code 13.

Also check the Ardity setup guide which eases the ramp up (download it here).

There is a provided sample scene showing bidirectional communication, you'll need that as you need to send commands to the encoder before getting the results back.

Let me know if you have more doubts,
Regards, Daniel W.

[Lenakeiz]

Hi Daniel,

Thank you for your reply. Your code works pretty nice although I get the following error if sending a reading command each of the Unity update.

Exception: The semaphore timeout period has expired.
StackTrace: at System.IO.Ports.WinSerialStream.ReportIOError (System.String optional_arg) [0x00000] in :0
at System.IO.Ports.WinSerialStream.Write (System.Byte[] buffer, Int32 offset, Int32 count) [0x00000] in :0
at System.IO.Ports.SerialPort.Write (System.Byte[] buffer, Int32 offset, Int32 count) [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.IO.Ports.SerialPort:Write (byte[],int,int)
at SerialThreadBinaryDelimited.SendToWire (System.Object message, System.IO.Ports.SerialPort serialPort) [0x0000e] in C:\vrlab\Assets\Plugins\Scripts\Threads\SerialThreadCustomDelimiter.cs:47
at AbstractSerialThread.RunOnce () [0x00025] in C:\vrlab\Assets\Plugins\Scripts\Threads\AbstractSerialThread.cs:280
at AbstractSerialThread.RunForever () [0x00015] in C:\vrlab\Assets\Plugins\Scripts\Threads\AbstractSerialThread.cs:165
UnityEngine.Debug:LogWarning(Object)
AbstractSerialThread:RunForever() (at Assets/Plugins/Scripts/Threads/AbstractSerialThread.cs:172)

Not sure why that happens but I guess it has something to do with the queue becoming full.
Do you have any hint of why it s doing this?

Cheers,

Andrea

[dwilches]

Hi,
I'm sorry I had not seen your reply, my GitHub email settings were off.

That's a bizarre error you mention, it seems to be something internal to the Windows API for serial communication. Some guesses:

• Maybe the baud rate is too high? Can you try setting a lower baudrate in both Ardity and your Arduino program?
• I doubt it has to do with Ardity's queue getting full, as the error is generated when Ardity is trying to send a message to Arduino. Maybe the Arduino program is not reading events so often so the incoming queue on the Arduino side gets full?

Regards.