ZLINE is a system I am working on that allows me to interface my PIC Dev board to LabVIEW. Currently this is done over RS-232 using VISA. On the PIC side, I have a simple firmware that looks for commands. Currently everything is done using what are essentially peek and poke commands. Using a collection of VI's in LabVIEW, using this system is quite simple.

Writting simple VI's that use the PIC is fairly straight foward. Once the ZLINE session is open, its as simple as writting to or reading from a register. Instead of needing to know the memory address of the needed register, an enum is used that lists the registers. More complex VI's can be created from these for doing operations such as using the PIC's A/D or PWM modules.

One possible application could be using the PIC as a simple PWM generator. Once the PWM module of the PIC is set up, changing the PWM is as simple as sending a byte. If using a PIC with multiple PWM output channels, complex controllers can be made in LabVIEW and output by the PIC.

While the current firmware was writting for the PIC18F4550, it is possible for this system to work with just about any chip in the PIC18 family. The largest difference between any would be if any of the memory addresses for the different modules are different, which would require a change in the VI that returns the actual address from what enum selection was made. Running different PIC familys would also be possible if the above change as made above as well as porting the firmware over to the different family.

Currently there is one potential issue I have found. There is a fairly large delay between when a VISA write is performed and then a read. Everytime a register write is performed, the PIC replies with an acknowledge that lets LabVIEW know that the PIC is still running and that the command was received correctly. To measure the possibly output speed of the system, I had LabVIEW toggle a bit on PORTB in a loop with out any kind of delay or other LabVIEW code. The frequency of the output was around 250hz, which is a lot lower then I had hoped. If I had the LabVIEW code build up a large string that corresponded to the the command and data to perform the toggle and sent it, the frequency was over 1KHz (what it was exactly I can't remember). This brings me to the conlusion that for any operations needing to be done at a rate over 250hz, a sample will need to be created in the form of a single string of commands and sent. This would be similar to how NI's own DAQs function in that everything is a finite sample size.

Eventually I would like to increase the amount of PIC side commands to help overcome the VISA latency. Instead of running through the multiple reg write commands in LabVIEW needed to perform different operations such as configuring modules, single commands that will do all the set up. For example, to set up a PWM output by writing to each register in LabVIEW would take about five or six reg write commands, when alls that is needed is a command with two data arguments for frequency and pulse width.