04-30-2014 04:32 AM
Hello to everybody!
We are buying a PC-based device having an NI-GPIB board used by the software to communicate with the external world.
Normally I'm expected to use the following architecture:
PC With GPIB interface running My software >-----GPIB Cable -----> Device with NI-GPIB Interface running its own closed-source software.
Since the Device is Windows based can I move my program on the device?
In other words: can the two programs, while running on the same PC, share the same GPIB interface to talk to each other?
Thanks in advance for any help!
Marco
04-30-2014 06:48 AM
Interesting question
It should be possible to use another GPIB adopter in the same Windows machine and assign different addresses other than the existing one used by the Device Software. In effect you will have two NI GPIB controllers, one is used by the Device Software and another one is used by Custom LabVIEW Software. In this case you will be using two GPIB controllers and assign two different addresses and connect them using a cable.
I am not sure if we have any software in market which will emulate virtual GPIB hardware and talk to NI GPIB card using the communication layer in the same Windows machine.
04-30-2014 06:56 AM
I wouldn't think so. I wouldn't think an instrument would be able to have a GPIB controller. It would only be a receiver. You might be able to communicate to the instrument software using TCP, assuming you know what ports are available to communicate with.
From a security stand point, it is better to leave the instrument alone and just communicate it over a GPIB cable with another machine.
04-30-2014 09:24 AM
Hi and thank you both for your comments.
I had this idea to move my program to same computer of the device reading this knoledgebase:
http://digital.ni.com/public.nsf/allkb/C42CDC77C00E0B8086256E9B0078F887
According to this document it is possible for a Program A to communicate with Device 1 sharing the same interface with Program B communicating with Device 2.
I was then curious about the possibility to communicate from Program 1 to Program 2 via GPIB interface.
But maybe it is too much to ask the GPIB board to act as a controller for Program 1 and ,at the same time, as a listener/talker for Program 2.
I'll let you know any further developement.
Regards,
Marco
05-01-2014 09:07 AM
I was then curious about the possibility to communicate from Program 1 to Program 2 via GPIB interface.
That may or may not be possible (I've never tried it) but it is sort of foolish. To communicate between applications use an appropriate data transfer mechanism. a single process shared variable comes to mind. or even a temporary file.
05-02-2014 12:53 AM
I completely agree with you, Jeff.
But the issue here is that one of the applications is closed source and communicates with the world through GPIB.
Marco
05-03-2014 06:42 PM - edited 05-03-2014 06:49 PM
@MarcoMauri wrote:
I completely agree with you, Jeff.
But the issue here is that one of the applications is closed source and communicates with the world through GPIB.
Marco
well, that is exactly why HPIB was invented. Pass CIC! and let the onboard processors take control of the whole system........but MyProcessA to MyProcessB communications ---- that does not work well. It can be made to work! Using that bus!
Have you played "Oregon trail" lately? in the 1960s it was sometimes necessary ,due to the lack of higher level languaguges, to program with the silicone onboaod the instrument in the loop (and baud rate limitations). There are much more effective methods today. Software defined hardware is a "New Technoledgy" Can you provide a use case?