Neville D

I recall reading about USB adapters with the FTDI chipset being the most reliable. Try to get one that has that. I recently bought a USB-RS485 adapter from http://www.rs232-converters.com/USB_to_serial_adapters/USB_to_rs232_rs485_rs422_ttl_converter.htm It works fine.

There seems to be a bug in the Modbus CRC calculation vi in the NI library. Replace it with the attached VI that I got from Steve Brooks on the NI website. MBcrc.vi

Maybe you can borrow an equivalent one from your local NI rep. If I remember correctly that is a pretty old card and replaced by a newer version with more bits, but function calls etc should be the same.

Hi all, working on my first reconfigurable IO project using a PXI 7811R with LabVIEW RT. I am building a quadrature encoder counter using a couple of the NI examples, and was wondering if there were any caveats to changing it to use an I-64 as the counter output? The NI example uses a 32 bit integer for the count. In my version, I changed it to an I64 count output and added a speed (counting ticks between pulses) output as well. It seems to work fine, but would appreciate any cautions that experienced FPGA users might have. Neville. PS. Cross posted to info-LabVIEW as well.

How many shared variables are you using? I have around 70 or so communicating with a PXI LVRT target, with no problems. What kind of target do you have? Hosting large numbers of shared variables on smaller/older targets cFP or FP might be an issue. I haven't investigated this but: you could put password protected indicators on a tab sheet and hide/display the entire tab or that particular tab on the RT front panel. Again, I don't know if those tab properties will work on RT. They might.

Why don't you add the password functionality in the calling Host VI instead of adding to the RT panel? When user presses a button to open the panel, force them to input a password before actually opening the panel.

Have you tried using continuous samples instead of finite samples?

Thanks Jon.

Hi, does anyone know the link to download the NIWEEK 2011 presentations?

Have you tried a mass compile of the entire project?

Hi guys, I downloaded the Mark's excellent Icon Editor a while back, and don't remember what slight changes I made, but in my case, clicking on the "NI Icon Editor" button calls the NEW NI Icon Editor. I really hate it, so I just press the ABORT button on Mark's Icon Editor, and that calls up the OLD NI Editor, in the few cases I need to modify an icon to keep the pictures previously set. As an aside, Mark it would be great if you could add a feature where, you could edit the Icon History to delete some icons. The use case for this is: say you build an icon, and plonk down the VI on a block diagram, now you find the icon is hard to read because of the colours chosen, I frequently go in and adjust (lighten) the colours a bit, and use that. But the icon history now has two versions of the same colour scheme, each slightly different, and can trip you up if you re-use the wrong one the next time around. Neville.

Roo, I would suggest going through the examples, now that you have tried the Express VI. You can also right-click the express VI and open it up to see what the code is doing inside. The Express Vi is just to get you started. In general, its not a good idea to use that for an application since it has a lot of code in it that you may not be need in your specific case, slowing down your application. Try getting one camera up and running as you want it, then duplicate the loop for two cameras. N.

Paracha, that VI's operation is not relevant to the Datasocket communication illustrated. Its just some housekeeping on the data acquired. N.

Hmm.. not sure what version you are using but I have used 8.6.1, 2009 and 2010 with static and dynamically called Shared variables, with no problems. I have about 80 of them and 3 or so are read dynamically in the PC Host. The SVE is hosted on the RT PXI target. Neville.

I remember having the exact same problem, but I don't remember what I did to fix it.. have you tried just ignoring the warning and trying to work with it anyway? Maybe a reboot? Neville.

I'm still not clear as to what you are trying to accomplish/improve. Maybe a screenshot of the specific part of your code would help. Reading all those temperature channels means your sample rate can be very slow without affecting accuracy. So what if you have to start and stop the task? You will not be running the loops at kHz speeds any way, so the few ms when you don't have data when the task is being set up are not that important, considering your loop should be running around once a second or slower. And why bother with MAX? Just configure the channels as you need in your code itself. You don't really need MAX except when trouble shooting initial wiring etc. You can also save your channel configuration generated in the code to MAX if you need. Split the "slow" and fast channels into two or more separate tasks, read them in their respective software timed loops (can be either while or timed loops), write generated data to a Q to process in a separate loop and your done. Maybe a stop button to stop and clean up when finished. N.

In my experience, they are quite reliable; most bugs have been traced to code other developers have written, rather than any issue with the shared variables themselves. Couple of points: 1 "Important" (regularly updated, critical) shared variables are read using the DataSocket API, where I connect to the SV engine on the RT target, and then monitor the status of my connection. If it goes down, I reconnect, kind of like a TCP loop. The read values are then Q'ed. Prior to implementing the reads in this way, I would get SV's go down when the RT target was being rebooted, and they wouldn't "reconnect" without restarting the HMI (PC) application. 2 Once connection is re-established, the other static Shared variables seem to connect without a problem. Runtime for built executables (between reboots) can be 8 or 9 days. 3 The Shared Variables are hosted on the RT target and number about 70 or so; some are complex clusters, others are SGL's, DBL's, and even an IMAQ image flattened as a string. Some values are buffered, others are not. Here are some screenshots: Neville.

Look up "Producer Consumer" architecture in the LabVIEW help. Neville.

Can you describe your application in a bit more detail? If you are scanning digital channels, may be you could use change detection on the channels? How about setting up the channels that don't need to be scanned multiple times in one task and the other channels in separate tasks? Neville.

In the past, having graphs/charts transparent and overlaid caused the drawing updates on panels to be drastically slowed down when LV tries to draw and then redraw the layers above. Try to avoid transparency or else make sure transparent elements are not overlaid on each other. But I agree, panel drawing routines especially for charts/graphs have been a performance bottle-neck for ages. In this day of streaming video, and using video cards as co-processors for FFT's, having an application fall to its knees when plotting data is a bit ridiculous. NI really need to work on improving performance in this area. N.

You could get an eye tracker with a PCI slot, mounting it in the ETS (realtime) PC.. really its exactly the same as PXI, but minus the Star trigger bus. But PXI is a more robust (though expensive, when you factor in chassis+controller) solution. Requirements for using a desktop PC as a LabVIEW Real time target Yes, that will work with LV-RT as well. We have written C dll's and called them in RT before. As an aside, I notice that there is an " Real time Execution Trace Toolkit" for LabWindows as well (in the latest LW 2010 SP1 Release Notes). Have fun! N.

Are the 16 channels all acquired simultaneously at the same rate, and starting together? I think that is totally possible. However if you want to acquire them at different rates, then you would have to break them out on different cards since each card has only one sample clock. The PXI is equipped with an internal trigger bus as well as RTSI lines, so you should be able to route your start trigger to a separate DIO card to start the DIO operations with the AI task. You could also use a PC with certain specifications on the ethernet chipset and such, as a realtime platform. The setup might take a bit of time, but once established, it behaves just like a PXI platform (but cheaper, and you need a RT runtime licence). It probably will not have the PXI's star-trigger bus, which might be required in your application. Again, I am not sure if LWindows RT will run on the PC, but if LV-RT can, I am assuming it is possible with LW-RT as well. You can then buy NI's PCI versions of DAQ cards and use those in the LW-RT environment on the PC. Also, the PXI controller comes in an extended temperature option and usually stands up quite well to harsh environments. There is a LabWINDOWS realtime module as well which I am almost certain should run on PXI. I have never used it so no idea of its debug capabilities. http://www.ni.com/lwcvi/realtime/ Some points learned through experience: 1 When you have a choice between "low-cost" NI hardware and more expensive, go with the more expensive. You will almost certainly need some functionality (more DMA channels etc.) in the more expensive card as you go further along your development. 2 Pay careful attention to the number of modules. ALWAYS get the 8 slot PXI chassis at the very minimum (you might need the 13 slot). I have been bitten in the past with getting the 4slot or the 5slot then being stuck with $1500 hardware that can't be upgraded or easily replaced without ending up with unused hardware. 3 Get the latest/greatest/fastest PXI controller you can (from NI since you need the RT support). Getting older hardware is a recipe for lots of pain and heartache. If you go with PXI, you always have the option of using LabVIEW RT as well, if you think of going that route. The debug tools and communication tools there are excellent. I have just recently finished debugging a PXI RT system with Counter, DI, DO, and image acquisition using the RT Trace execution toolkit. Its great (once you understand how it works, with the very spartan documentation available). The network streams API would be perfect for deterministic communication as well. Good luck and keep us appraised of your progress. Neville.

What hardware are you using? Most NI Multifunction hardware have a couple of counters already built in on the card. N.

Are the 16 channels all acquired simultaneously at the same rate, and starting together? I think that is totally possible. However if you want to acquire them at different rates, then you would have to break them out on different cards since each card has only one sample clock. The PXI is equipped with an internal trigger bus as well as RTSI lines, so you should be able to route your start trigger to a separate DIO card to start the DIO operations with the AI task. Do you have any proprietary/non-NI hardware you will be using? I am not sure how that would translate to the PXI platform. You could also use a PC with certain specifications on the ethernet chipset and such, as a realtime platform (check out "ETS" on NI's website). The setup might take a bit of time and research, but once established, it behaves just like a PXI platform (but cheaper, and you need a RT runtime licence). It probably will not have the PXI's star-trigger bus, which might be required in your application, but you can use the RTSI bus. Again, I am not sure if LWindows RT will run on the PC, but if LV-RT can, I am assuming it is possible with LW-RT as well. You can then buy NI's PCI versions of DAQ cards and use those in the LW-RT environment on the PC. Using this setup you can easily and cheaply upgrade the PC with the latest/fastest processor, down the road. No need for a chassis for the DAQ card as well. However, the PXI controller comes in an extended temperature option, usually stands up quite well to harsh environments, and works right away painlessly with RT. There is a LabWINDOWS realtime module as well which I am almost certain should run on PXI. I have never used it so no idea of its debug capabilities. http://www.ni.com/lwcvi/realtime/ Some points learned through experience: 1 When you have a choice between "low-cost" NI hardware and more expensive, go with the more expensive. You will almost certainly need some functionality (more DMA channels etc.) in the more expensive card as you go further along your development. 2 Pay careful attention to the number of modules. ALWAYS get the 8 slot PXI chassis at the very minimum (you might need the 13 slot). I have been bitten in the past with getting the 4slot or the 5slot then being stuck with $1500 hardware that can't be upgraded or easily replaced without ending up with unused hardware. 3 Get the latest/greatest/fastest PXI controller you can (from NI since you need the RT support). Getting older hardware is a recipe for lots of pain and heartache. If you go with PXI, you always have the option of using LabVIEW RT as well, if you think of going that route. The debug tools and communication tools there are excellent. I have just recently finished debugging a PXI RT system with Counter, DI, DO, and image acquisition using the RT Trace execution toolkit. Its great (once you understand how it works, with the very spartan documentation available). The network streams API would be perfect for deterministic communication as well. Good luck and keep us appraised of your progress. Neville.

Farid, Jon has posted a VI snippet. Download it and you should be able to run the code. Search the examples in LabVIEW for "subpanel".. it should bring up some useful stuff. N.