I'm not using this IO ports at the moment but used to do it in the old days. In fact we were glad that an IO system was protected by the OS.
Ok sometimes it is easier to use this than to do it the correct way but the OS should protect us from hurting ourselv to easily.
Especially memory IO but you are not talking about these.
Setting up a special IOspace like the VISA-USB possibilities and the way I can write to an IO-card via VISA are more appropriate I guess.
Maybe you should make it easier to work via VISA than to open the old hole again.
Sure no other type of IO will be available than USB in a few years. No parallel port, no serial port so why not give us examples and cheap hardware solutions for that channel. The NI usb modules 6008 and 6009 are not that expensive but still to expensive for hobbyist users.
So I'm not against opening up an IO system but more via a VISA like way than via portIO.
As long as I have a printer port on my PC I want to be able to access it!
More general: I think LabVIEW should give me all possible access to the current 'standard' hardware, just because it's there.
Hey, you have a peace of hardware (personal computer), your wonderful software and an (more or less wonderful) idea to join them. And then you get the message: ' Sorry, you are not allowed to access your own hardware' OK, we are there already..
I wouldn't need and use memory access if I have the chance to toggle or poll an exsisting IO-line via VIs that handle it. What type of driver that VIs belong to....VISA/DAQ/DLL/NET/?? who cares?
Just my 2C
Have a nice weekend
Thanks for replying. Since you mentioned the printer port, I have some follow-up questions:
For what kinds of applications do you require access to the printer port?
The current LabVIEW API for NI-VISA will allow you to write messages to the parallel port by treating it as a quasi-serial port. It will not allow you to arbitrarily write to the parallel port's registers. Is the latter use case important to you?
We using labview In Out functions to create custom SPI communication with our Eval board thru Printer port.
I understand there are alternatives but we need to keep cost of eval kit to minimun and avoid shipping any extra hardware.
In this respect iit is very important to have access to individual bits in registers.
We have used LabVIEW's In Port and Out Port VIs to implement an interface to a in house developed test board.
The board was developed previously and had a Printer port interface operating in EPP-mode.
We wanted to interface the board to LabVIEW, and had prior to LV7 only the option to write a NT device driver for the board ( in C++)
No we could use In Port and Out Port VIs, to directly build a LabVIEW interface.
The main advantage is the reduced the competence requirements for maintainance of the software.
Also of course, the architecture got much simpler.
So KEEP this functionality
One of the problems with inport and outport in the old form was that I had no block operations. Each byte or word had to search its way through the operating system. This takes a lot of time.
Is it now possible to do arrays of bytes out, and in and what about a busy or clk line?
for simple SPI / I2C communication on bread boards
I adapted the llb from wha@atmel to my needs that uses the port in/out, Never thought about using the VISA read write. Didn't the VISA read would need something toggled on the port to read ? (No time for test right now...)