> So for NI488.2 it is clear, I will go finding the > new stuff in their site... I hope to find ;-) > It would be great if they have produced some > table with the old and the new calls. I'll dig. > > For porlogix I'll take a look at the timelab source, > good idea. At the moment I don't own one > and was in my concerns if I could actually write > code for it not too differently from what I already know... > Before I get one ;-) > > Thanks, that was exactly the starter info I was looking.
Note that you can just copy gpibport.cpp into your project to get support for all three -- NI488.2, Prologix GPIB, and Prologix LAN -- with the same API. That way you wouldn't need to look at the NI488.2 documentation at all, except to add support for functions that aren't abstracted by gpibport. GPIBPORT::set_connection_properties() will take an identifier string like "GPIB0" for NI hardware, "COM3" for Prologix GPIB-USB, "192.168.100.1" for Prologix GPIB-LAN, or "COM1:baud=9600 parity=N data=8 stop=1" for generic RS-232 support without Prologix markup. Some counters like the SR 620 can use any of the four interface types, since they have standard GPIB ports and also allow GPIB-style control through their serial ports, so that module needed to be able to enumerate all of the possible connection types and handle them polymorphically, so to speak. The source file drivers\GPIB_TIC\GPIB_TIC.cpp is probably the best example to look at if you want to use the gpibport API. The only real hardware-dependent stuff is in ACQ_CONTEXT::select_port(), where it builds the selection list of interfaces and ports found on the user's system. -- john _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.