Can an GPIB-USB-HS appear as a serial COM port?

[G Marshall]

I have a PC that controls some local hardware and several remote devices connected over RS232. This works fine since my controlling software (Aerotech motion control MMI) can talk to RS232 serial COM ports with ease. Now I need to communicate with a device that has only a GPIB interface. So I have installed my GPIB-USB-HS (that I already have in the lab) and would like to make a device on this interface appear as if it is connected to a local serial COM port. Is this possible?

I guess I'm asking whether I can configure the NI488.2 software suite (or something else) to make a 'fake' local COM port that I can talk over with my serial-only software. Unfortunately I can't use the GPIB-USB-HS with the Aerotech software and I can't use LabVIEW to access all the features I'm using in the Aerotech software.

I realise that there are NI devices such as the GPIB-RS232... boxes but I want to avoid spending more money on an interface!

[Dennis_Knutson]

No, you can't make the GPIB appear as a com port. It's likely that the software vendor uses some low level serial only driver that works only with a real RS-232 port. If they were smart, they would have used VISA which makes GPIB/Serial/USB/Ethernet all transparent. You might want to check with them to see if they actually did and if they didn't ask them why not.

[G Marshall]

Interesting, thanks Dennis. What I'll probably end up doing then is writing a little LabVIEW buffer program that acts as interpreter for the serial/GPIB ports. That way my older software can open one com port while LabVIEW listens on another and spits out and listens to data on the GPIB line.

[MCEddieD]

Were you ever able to get this to work?

I'm in a similar boat where I have a 30yo+ system we are migrating to a new hardware and user interface platform. To split the development phases; I'm trying to migrate all the hardware immediately and keep the old user interface software blind to this. The older DAQ hardware uses GPIB and we run it through the GPIB-USB-HS converter on the host computer where a HATBASIC user interface program starts/stops the acquisition process and reads/processes data. 

Rather than have a mix of sotware/hardware development in the middle of client testing, I have a two step process to get us on the new hardware asap:

1. Run the GPIB-USB-HS to the new embedded PC doing all the real-time work. This PC has the ability to transparently route the USB interface over cat5 back up to the old user interface program, where the NI drivers will pick it up and read the data.

2. Step two involves creating a small program on the new embedded PC DAQ hardware that will stuff the "new" data into a format identical to the old data acquisition hardware, and pass it up to the old UI over virtualized USB port on a cat5 cable.

Step 1 is validated, and for the second step, I'm trying to avoid purchasing the GPIB-RS232 module if I can. I could also just use two GPIB-USB-HS converters (run out of the new daq computer on the usb side, GPIB ends of the two converters attach together with the right adapter at the mating point, then the other converters USB end will plug into the host. This effectively turns my new DAQ embedded hardware into a GPIB enabled device. But again, I would have to buy another adapter; they aren't too cheap.   

Any thoughts or insights from this project you were working on a while back?

[AvatarAang]

Hi, McEddieD,

I noticed that this original forum post and reply are 10 years old! The visibility of this post is therefore not great... Try posting it as a new post and include the link to this old post. You're almost guaranteed an answer by the community if it's posted in a higher-traffic area of the site.

[maherhome]

Just trying to do this today.  Frustrating. 

[maherhome]

FYI we ended up using a Prologix adapter.  Works great.