VCP troubles with 3rd party CANbus adapter

[markmakeitso]

Hello,

I'm having troubles connecting to a third party CANbus adapter, the EasySync USB2-F-7001.

http://www.easysync-ltd.com/product/556/usb2-f-7001.html

I've been using VCP commands to control the CAN connection with no problems for literally several years, until LV2012 SP1 was installed instead of 8.6. Ever since then the device won't respond to any commands from LV. Hyperterminal will connect perfectly using the same port settings, and Device Manager claims it is working properly. When the LV update went through I asked IT to not upgrade to Win7 as planned, since I had read that VCPs and 7 didn't play nicely, but it's still having quite a bit of trouble in XP.

My setup:

WinXP SP2

LV2012 SP1

VISA version of implementation: 5.3

VISA version of specification: 5.1

The VISA resource selector shows the correct COM port, and no errors are reported during an attempted connection. I'm fairly sure that another program isn't using the port, and adding a VISA close port command before initializing causes error -107367418.

In the VISA Interactive Control the COM port is shown as "ASRL3::INSTR" and hovering over shows the device name, so that seems to work correctly. The closest to a clue I've found is that under View Attributes the "Is Port Connected" line (VI_ATTR_ASLR_CONNECTED) at the bottom is in red, and "Invalid Property Value" is in the Current Value column. I changed the assigned port setting in Device Manager to 11 and 12, both changes are shown in Interactive Control, but with the same line in red. I made a simple serial device VI to just initialize the port, TX, check bytes at port, and close the port when done. Also no dice.

The device does have some commands that can be used without a CANbus network connected, "V" and "N" commands return characters for version and serial numbers. Is using the Basic I/O menu a viable way to check for responses? Any other suggestions on ways to get it communicating again?

Thanks,

Mark

[Dennis_Knutson]

The attribute that you are so concerned about should be ignored since it is only for NI serial devices.

I'm not sure what it's wrong since you are able to successfully communicate with some commands. I would check with ftdi to see if you are using the latest driver.

[markmakeitso]

Hi Dennis, thanks for the reply.

To clarify, I meant that the device supports several single byte commands that give a character response back. They haven't worked in LV2012 yet, although Hyperterminal functions. If that attribute list is only for NI serial devices does that mean the Input/Output functions won't work either?

So far I had been using the drivers listed for the device, but I will check for FTDI drivers, per your suggestions. Some digging around for FTDI solutions did reveal a bit of weaping and gnashing of teeth. We'll see.

Thanks,
Mark

[Dennis_Knutson]

It does not mean the I/O functions should not work. As I said, you should ignore it.

I've had great success with FTDI and the web site says that is what you hardware uses.

You might be missing something in your code that hyperterminal is doing (i.e. a termination character). You can use portmon from Microsoft to capture the writes and do a comparison.

[markmakeitso]

Hi Dennis,

Tried out PortMon, and made a couple recordings from both Hyperterminal and LV. The biggest difference in LV is calls to IRP_MJ_FLUSH_BUFFERS, immediately after write operations. That's followed up by a relatively quick call to IOCTL_SERIAL_GET_COMMSTATUS. Seems like a similar problem to this thread, which didn't list a solution:

http://forums.ni.com/t5/LabVIEW/How-do-I-stop-a-flush-buffers-after-a-VISA-write/m-p/211656#M119424

Besides "BUFFERS" plural in the call, it seems the PC TX buffer is definitely being flushed. The V and N commands should return several characters, but the O and C commands should only cause the device to open and close, which is indicated by a solid green LED which doesn't change during LV communication. I guess that the very small delay between write commands and the buffer flush also indicates that pairing. The CANbus device can stay open even if Hyperterminal closes, perhaps possible to connect to an active CANbus network, close HT normally or through Task Manager, then open in LV while it's already streaming?

We might still have a PC with an 8.X floating around that I could also try to see if that's the key difference. Craigherdman's suggestion from that post might have some merit, but I'm not exactly sure off the top of my head how to implement a software buffer. Seems that original poster was using a hardware RS-232 port, and a VCP doesn't have dedicated hardware resources as such.

General aside, thanks for the suggestion on PortMon, that will be really helpful when I'm interfacing microcontroller devices to LV.

[markmakeitso]

Follow up solution here. Seems to have been a problem with 2 root issues. First of all, the IRP_MJ_FLUSH_BUFFERS calls which were flushing my TX bytes stopped when I used the VISA Set I/O Buffer Size. This worked in the VISA test panel first, then was verified in my VI. My second issue is that the Enable Termination Character input on my VISA serial TX doesn't seem to function properly. Eventually I resorted to adding a carriage return (\r) to each TX string, as shown in this thread:

http://forums.ni.com/t5/LabVIEW/How-can-one-write-text-commands-to-a-usb-device-through-VISA/m-p/333...

Thanks WNM, your advice is helping out years later.

Using both of these fixes together I was able to open and close the CANbus channel, and also successfully read the multibyte responses to the V and N commands supported by the device. Still need to ensure the frame TX and RX functions work properly, but I'm fairly certain they will. I'll probably add a manual option to my main VI to attach a terminal character to any VCP TX functions.

Also thanks to Dennis, you're suggestion to try Portmon was the key to getting back connected. Appreciated.