This is a call for any and all feedback regarding the LabVIEW for CompactRIO Developer's Guide. If you have stumbled upon this guide and attempted to reference it during your development, please take a moment to share your candid thoughts.
Some questions to consider:
- why did you seek out this guide? what problem were you trying to solve?
- what did you like most about the guide?
- what was your overall impression?
- what didn't you like, or what content do you feel is missing?
Thanks in advance!
I already downloaded this Guide and I am still reading it
but really I liked it too much, I liked most the way it describe how to make your applicaion into steps of defining your task and then defining which processes these task will do.. and the block diagrams that shows the communications between the RT , FPGA and the UI...The ways and methods of communicaions is well defined..
A good example was includded concerning the wind turbine and others.....the ideas was applied on this example..
I have downloaded this gide because I want to use this ideas for task on sbRIO, and I think this guide is general for any NI RIO devices.....thanks
I'm quite new to LabVIEW and especially the CompactRIO hardware.
The guide comes in very handy to get started, and -in my opinion- it can even be very interesting for more advanced users.
However, I'm running into a small problem, which maybe other users can help to solve?
On my personal PC, I'm using LabVIEW 2013, which includes the sample projects for the compactRIO.
On my development & measurement PC in the lab, I'm limited to LabVIEW 2011 due to the policy within our research group at university.
The development PC will run the actual software and will be connected to a compactRIO 9074.
However, when I save the sample project in LV2013 for LV2011, I run into 2 errors:
-The element allocation mode terminal of the Create Network Stream Endpoint node is not supported in this previous version of LabVIEW. This input has been disconnected and all elements will be allocated as needed. (4 warnings)
- Polymorphic VI may break in a previous version of LabVIEW. (1 warning)
I'm wondering what might be the best way to solve this issue, since I prefer to work with the sample projects, due to my lack of experience and to get everything started.
During my own search, I found the bioreactor control example, but I noted that the general setup of the VI is a bit different for what's being used nowadays.
Is there a decent way to save the current (LV2013) sample projects for LV2011, or is there another example file which works on LV2011 but uses the recent programming methods?
Thank you for the feedback on the Developer's Guide and Sample Projects. I just checked our 2013 sample project, and the "element allocation mode" input on the Network Stream Create Network Stream Endpoint function is not used, so you can probably ignore those warnings. I'm guessing that terminal was not available in 2011 and earlier, which is why you received the warning.
For the polymorphic VI that broke - I'm not sure which VI the error message is referring to - does it give you any more details? I'm guessing that it's something you can also ignore, but I could be wrong.
Let me know - thanks!
The polymorphic VI gives following warning message:
..\RT Loops\RT Loop - System Health and Monitoring.vi (RT Loop - System Health and Monitoring.vi)
The polymorphic VI "Close.vi" has instances that contain required terminals. LabVIEW may break this subVI call in the previous version.
For the Create Network Stream Endpoint node, the warning is referring to the RT Loop - UI Commands VI, in which the function is used if I'm not mistaking.
The Turbine Testing example project yields two (other) warnings, also on the Create Network Stream Endpoint node. I will try out whether it works properly or not when I have access to the cRIO
Which sample project are you using? I should be able to send you a working version. Is it FPGA Control, Real-Time Control, Real-Time Sequencer, or Waveform Acquisition and Logging?
Hi Meghan, I'm using the Real-Time Control sample project.
Edit: In order to avoid any confusion about the errors, I have added the warnings in attachment to this message.
I'm new-ish to cRIO (an application user for ~1yr, experimenting for ~4months and now developing first application) and have found the developers guide very useful. It took a while to find it though, I think I came across it almost by chance.
- why did you seek out this guide? Found it by chance, should be better sign posted.
- what problem were you trying to solve? Need to learn how to develop cRIO applications for scientific experimental rigs.
- what did you like most about the guide? Factual, no marketing, step by step, clear explanations, doesn't try to make it any simpler or more complicated than it actually is.
- what was your overall impression? Good
- what didn't you like, or what content do you feel is missing? A bit verbose in some respects e.g. interprocess/target comminication, seem like it takes a long time to get to the information about how to actually do some thing. Recognised that you have a lot to explain and a wide range of audience prior knowledge.
Specific feedback is that I think the figures and figure annotation at the begninning of chapter 13 may not be correct, or I am missunderstanding. The text could do with some inline references to the figures also.
Fig 13.1 seems to be related to the sequencer example, not FPGA control.
Fig 13.2 is identical to Fig 13.4 but each has different annotation.
Fig 13.3 makes sense.
Fig 13.4 makes sense but see 13.2 above.
Fig 13.5 makes sense.
Fig 13.6 makes sense in terms of its location within the text but the text above it references 13.1, which is a different diagram.
The document as I have printed doesn't have any date or version number shown on it, however a fresh download this morning seems to be identical in this respect.
Please could you clarify and if necessary correct this.
I really like the Developer's Guide and I need to keep going back to it for reference. Thanks so much for putting it together!
One thing I think it needs is a section on how to synchronize cRIO clocks to hosts (Windows PCs in our case) and to keep them synchronized. In our case, we want to keep the cRIO real time clock slaved to the Windows clock even though the cRIO clock is probably more accurate.
NTP, 1588, NI-TimeSync: which is the best to use for a given situation and how do you actually go about implementing them?
NTP and 1588 are both network time protocols and are both options. NI-TimeSync is a driver on the cRIO used for time sync so it's orthoginal to the decision.
NTP (or SNTP) synchronizes the clocks based on packets transfered between the devices and a time server hosted externally, normally at NIST. In this case your PC would sync to NIST and the cRIO would sync to NIST. NTP has the advantage that the PC and cRIO do not need to be on the same subnet and can work over large distances since they are using standard IP traffic (similar to if both were contacting the same external web page). Another positive is that the time each displays is the actual "wall clock", meaning that is is corrected and aligned with the actual date and time. The negatives are that it requires both have internet connection and the accuracy will be lower (expect 1s or so sync between the cRIO and PC). Another negative is that SNTP support is not native on all cRIO targets. We have some NI-Labs code and if you are using one of the new Linux targets there is a good external community to make this work well however it will require work on your part to make this work.
1588 is an end-to-end synchronization technology between devices. In this case the cRIO and PC would either directly sync to each other or to another "grand-master" clock. Advantages are that it can provide a higer level of time sync between the PC and cRIO (Windows will be the limitation but between cRIO systems we see <ms sync). It is also natively supported by all cRIO (the new Linux targets are still in-work so if you are using one of these targets we will need to help get you some pre-release versions of the driver). The negatives are that it requires all the devices are on the same subnet, Windows does not have a native 1588 driver (though there may be one you can download, I have not looked), and if you don't have a third party "grand-master" the time showed on each device may be different then "wall clock". In other words the PC and cRIO may think it is 1970 but both will think it is the same time in 1970. A Grand-master or other mechanisms to slave the 1588 master to another time source will correct this problem.
Some details that can help in making a decision:
What time sync accuracy do you need?
Do you need the systems to show wall clock time?
What cRIO system (or systems) do you have?
What is your network topology?
Do you have internet access?