Leaderboard

Hi Daklu, To answer your questions in more of an order of execution: Open FPGA VI Reference This VI can either connect to an existing running FPGA VI, if it is already running, or download the bitfile it is linked to if it is not. Whichever ever linking mechanism you use the runtime behaviour is the same. Linking to a bitfile will always work but linking to a build specification or VI will query the project at edit time for which bitfile is the correct one to use (or break the VI if it still requires compilation). I have not had a use for the other options for run when loaded yet! I always stick to the open reference (which I think is what will take precendence when you run your RT VI anyway, the others must be something edit time related I think). In the open reference VI, if run when loaded is selected the FPGA VI will immediately start. If unselected it is not started until you manual start it using an invoke node. This can be used to set intial register values before the code starting. If the VI is already running through some other means (such as it is already running), these functions will return a warning at run time. Close Reference Your problem in 2 is probably related to the Close FPGA reference VI. If you right click you have an option to close or by default close and reset. This means the FPGA VI is reset (read aborted in standard LV speak) when we close the reference. If you want it to continue you should change this to just close. FPGA Image Deployment If you want the FPGA to run continuously independent of any RT code you either need a piece of RT code that you use to deploy it initially by opening a reference and closing it without the reset. Or you can actually flash the VI to the FPGA using the RIO Device Setup application which will be in your start menu. This will even cause the VI to persist over power cycles as well. FPGA Top Level Re-entrancy Any FPGA VI is re-entrant by default, this makes the most sense more of the time on FPGA. For the top level VI though it will make no difference as you can only ever run one top level VI on the FPGA at a time. As it is a VI though this is just going to apply if you wanted to call it as a subVI. I hope this helps clarify a few points and I think covers your questions. Cheers, James

By 'multiple inheritance' I assume you mean multiplel levels of inheritance? If you're going to be downtyping through multiple levels of inheritance I'd take a hard look at your class relationships. Inheritance may not be the best way to accomplish what you're trying to do. In fact, since you have to create the signal object before knowing what kind of signal it is, I'd definitely look for an aggregation relationship instead of an inheritance relationship. Perhaps you could add a SignalProperties class as a member of the Signal class that contains the 20 attributes you referred to. Then when you know your signal is a diagnostic signal, you create a new DiagnosticSignal object and insert the SignalProperties class. As Mark said, typedefs are one way to address this, though I probably wouldn't use one. (Personal preference.) Each class is responsible for implementing it's own CopyData method to transfer data between different instances. If you're concerned that future developers might change the class data and forget to update the CopyData method, drop a comment on the class .ctl reminding them to update CopyData. Do you mean "all data from an ancestor" or "all data from all ancestors?" For the former, Mark's typedef suggestion, paying attention to changes, and unit testing can all help prevent errors. For the latter case, a string of CopyData methods from each of the ancestors clearly shows your intent and should be easy to verify by examination. (But like I said above, I'd look for a better way to accomplish your goal than forced downtyping. You code will be clearer and easier to maintain in the long run.) Mark, Why do you use the PRC prim in your copy method? The data copy from the source to the destination has already taken place, so by raising an error if the cast fails all you're doing is putting restrictions on how the copy method can be used. For example, the PRC prevents the user from copying parent data from a SubSubClass object to a SubClass object, or copying parent data between sibling classes. Did you intentionally implement that restriction, or is it to help make sure users are wiring the sub vi correctly? (Discovering the new use cases prompted me to relabel the terminals on my copy method to 'Source' and 'Destination' rather than 'Parent' and 'Child.') DowncastingObjects2.zip

The I32 is the current value of the listbox - it is its datatype. E.g. if the 3rd row is selected then the listbox = 2 (as LabVIEW counts from zero). So if you write 5 to a listbox indicator - the listbox will highlight the 6th row.