ShaunR

You want one of these then

Yup. This is where I was talking about type checking which has to be done in the child.

Well. TTestItem would contain your test info (upper limit, lower limit, measurement etc). If you think about it. What you are asking for is, in fact, a TList of TTestItem. You could, for example, create a TTestItems (note the plural) which would inherit from TList and this could be fed into TTests (which would also inherit from TList). So you would end up with a List, of a List of Testitems. This is how it would work in any other language and it sort of works in LabVIEW The point is. TList doesn't care what is in the list. It just provides the methods to manipulate a "List". The purists would (as I am describing) do all the inheritance then override where necessary in each child class (like with GetItemByName). I'm lazy though (and don't want hundreds of VIs). I just create TLists instances and add objects to them just as if it was an array of variants.That is the point where I stop using LVPOOP and use classic LabVIEW since all I'm interested in is using it instead of an Action Engine.

I think you misunderstood. You don't pass an array of objects into the the List (although you could with a TList.Init). The List IS an array of objects and you add the item using the "AddItem" method. So it is already exactly as you describe.

This is where we blur the edge of LVPOOP and Classic LabVIEW since LVPOOP is kind of a kludge. What I think are trying to do (as I have done on occasions) is to implement you own TList. (This terminology is a throwback to my Delphi programming). TList is a class with an array of Objects in the private data. The sort of methods that TList has are things like AddItem, RemoveItem, InsertItem, GetItemByIndex, GetItemByName etc and properties such as Count. It's arguable whether it is required, but I also have a TListItem class which has ItemName and ItemRef as the sole private data in the cluster (mainly because it fits with the hierarchy that I'm used to, but sometimes I use it to abuse the hierarchy). This is the class that I inherit from so I would have TTestItem cLass and TUserItem class and I would manipulate them with the TList. We could actually argue that what I have created is, in fact, a TCollection since any object can be in the list. This is of course generic. I could for example inherit TListBox (or TTreeList, TTableList et al.) from TList and enforce strictly typed TListboxItem (the latter of which would inherit from TListItem). But hang on. Don't we already have a TListbox? (the ListBox control). Nope. Because it is "Classic LabVIEW". It's properties and methods are all about the control as an object, not the contents of the Listbox which, in classic LabVIEW, is just an array of strings. So thats a lot of VI's just to enter and extract an array of strings, but it does mean you can also implement things like Sort and Reverse and claim "encapsulation".

I never said anything about fixed sized blocks. I think we will just have to agree to disagree.

What Ned said....... Another example (which would do what you want out-of-the-box) is Dispatcher in the CR.

You mean any ASCII instrument communication should use termination. I deal with many serial binary protocols where the message length is a number of bytes in the header. In theory. I agree with never using the bytes at serial port. However, the serial read can no longer be aborted. Not by making the Visa Ref go invalid and not even with the abort button on the LabVIEW bar! Unless you want your application to hang for, several seconds when the user exits (or you just want to stop the VI at all when debugging). The only practical way is to use your own read VI using the bytes at serial port in a loop with a very short timeout on the Serial Open (since you can only set a timeout on the open unlike other comms vis that are on the read). Then you can implement your own timeout without the VI hanging whilst VISA fiddles with it's gonads. This "feature" of the serial read has annoyed me enormously over the years.

I'm even worse (although I don't use a FG. Instead I use named queues) and only use strings for all my queues' data 1 VI for any queue anywhere within my code

I agree with everything Daklu has said (with the exception of efficiency but wholeheartedly with typos). Since I am firmly in the case structure camp for this stuff I would also add (in addition to my earlier posts which detail other aspects): Pros: Much smaller code base. Single point of maintenance, Better genericism (what do I mean? Discuss ). Looser coupling between messages and code (there is no code for messages). Less replication.(you don't need wizards or tools to save copying and pasting). Better portability (messages can easily be transmitted via ethernet, serial etc and interface to non-labview languages). Cons Typos (trivial) State difficult to handle (e.g. timed/timeout responses). Dynamic dispatch is a stealth case statement with handcuffs

Nope. It's a (2012) vanilla install (same in both 32 and 64 by-the-way).

You read the address then mask (and) the bit you are interested in to get that state. You will notice that the bits are 2^n so each bit represents the state of an output/input. So to get the state of "Control Contact 4", read the word at 0x026 then AND the result with 0x8. If it is greater than 0 (1), it is on; 0 it is off.

There is a broken VI in the latest version 0.3 (never seen this error before, presumably because I shy away from xnodes).

I would start with the "echo" command. Once you get that working (i.e. eliminate all the serial configurations and get something tangible back); it should be plain sailing from there.

Yup. It is a nice trick (refnum) because of the polymorphism that can be performed and it is "the right way". However. I have found that this is true only within LabVIEW and when dealing with interactions with external code, it is better (IMHO) to leave things in the native form for things like this since you only end up type casting it back to an integer to pump it into another call. I had the same sort of thoughts with the SQLite APIs SQL ref but left it as an integer in the end since every VI ended up with a type cast in and out.

The easy way would probably just expose it as a 32 bit value and if the user "must" have it, then make him deference with a moveblock (move the issue downstream). However, I'm not sure what you are asking here. If the DLL is 32 bit bit, then it can only be loaded in LV x32 (and therefore can only handle 32 bit pointers anyway). If it is a 64 bit, then that cannot be used by LV32 bit. So if the cluster uses a U64 it will be able to represent both even if it creates a "red dot" when passed to another API/DLL call which is set to pointer sized.

Well. The basics are that your PC will be a "master" on the bus (RS485 is multi-drop, meaning you can have multiple units on the same wires). You read/write to an address on the bus (the unit) and registers (memory locations) within the unit that correspond to configuration, inputs and outputs (outputs are sometimes called coils). Generally, the registers are device dependent so you will need the programming manual to identify them. However. It would be a good idea to start another thread so that we don't hijack this one.

Did you set the controller to use the Modbus protocol? Ummm. I posted a link to the NI Modbus vis which, you have now downloaded.

The controller isn't RS232. It is RS485 (according to the docs). Therefore hyperteminal or equivalent will not work. Looks like it has two modes of operation. CompoWay/F and Modbus. Modbus is an industry standard and, if you have the NI DCS module, you can set it up with the OPC server. Alternatively you can use the VIs I linked.

Nope. Still not convinced!. If they can spend oodles on POOP and trivial eye candy, then they can spend a fraction of that on standard OS event methods for the rest of us. It's not rocket science. GetMessage() in a while loop is windows only and a pretty poor way of doing it. If that is the method used, then it really does need a revamp. Although the currentEvent on the Mac could be an analogue, there is no equivalent in Linux (x11) as that is purely asynchronous. The bottom line is, NI have to "hook" into the OS message system (either by polling or by registering) to be able to get messages at all. They just don't publish all the messages to us. Whilst it would be nice to have a few more "generic" frames in the event structure that are available across all OSs (after all, there are a lot of similarities), that doesn't mean to say they cannot provide the raw messages in a frame so we can write platform specific software (like we do with activeX and .NET). Especially if they can't be bothered to wrap some of the common ones up for us ........and don't get me started with VISA events! I'm also not buying the "lock-up" and "dangerous situations" argument. All these methods are standard event messaging that applications must use to interact with the OSs and have well defined wrappers in most other languages. There are lots of code snippets around and they are all pretty much identical since they just call OS api functions (or X11/Xorg in Linux). Hooking events is very straight forward (as you are about to demonstrate ). If the argument boils down to "it's hard" (which I refute since they are already doing it for "some" events - for all the OSs) then that isn't really an excuse for a $4,000 piece of software from a multinational corporation that is quite prepared to come up with a whole new paradigm.

Nope. I don't buy it. Lots of features work on one platform but not another (because it doesn't exist) but that is beside the point. You don't have to implement the "500 Windows Message events and its 2000 variants", just expose the message hook (which they must already be using for the Event Structure on all platforms) and let the labview user filter what messages he/she wants with Gcode.

Rolf is about to give you a much better way

Yeah. snippits are a bit of a pain (better to post the code). In other browsers (like firefox) you have to open the image in a new tab/window, save/drag it to the desktop, then drag it to the VI.

Nice. If NI got off their arse and spent time on the event structure, they could easily have included this feature as a native part of the Event structure.

NI Data Finder