Yair

I find it amusing that you copied it with the spelling mistake, but I guess I'm too easily amused.

Bump. Is there a way for users to tell what the current version of the forums is? I don't see anything in the obvious places.

Modbus has a TCP/IP version, which is basically the same as the serial version. I assume cFP supports it, but I never used Modbus with FP, so that's just a guess.

Not necessarily. As others have alluded, there are times when LV will recompile a VI even if you haven't changed it (such as when you change a typedef it uses or the connector pane of a subVI). One way of working around this is setting the tread read-only VIs as locked switch in the LV options, but this would ideally require an SCC system which integrates with LV. As I mentioned in the NI thread, there is documentation about this, so you should read that.

I sent a reply to Info LV, but I might as well replicate it here - my basic suggestion was to either use Modbus or to use the DLL function CVI uses to work with DSTP or with the FieldPoint protocol directly.

Actually, I was being ironic (although I need to check with Alanis to be sure).

You're welcome.

I posted a reply in the other thread (basically that the EXE is a ZIPped folder). I know that people who post to the NI forums aren't worth much, but it would be nice if you add the cross-post link to both posts .

To find if an event is linked to a specific control, you can right click the structure and select Find Controls, which will highlight the controls for the current frame. I don't know these events either, but maybe Selection Change has to do with selecting elements in an array (a feature I never used, personally)?

I didn't look at your code, but you said the door was a numeric control, so all you need to do is right click it, select Create>>Property Node>>Position>>Top, which will drop a property node on the BD already linked to the control and with the top property selected. Now you can simply poll the shaft for its value (in a loop) and use that to calculate what the position of the door should be. If you want to get a little more fancy, you can even get the position, scale and size info of the shaft and use that to dynamically detemine where the door should go relative to the shaft, but that's already more complicated.

I'm pretty sure you can't do what you want, but you can control the placement of the "door" using the Top property by creating a property node for the door control. It requires some code, but it's the same as far as the end user is concerned. If you want to hide the code, you can make an XControl, but it's probably not worth the effort.

The basic rule for 64-bit LV is the same as it is for any other OS - you can open a VI you saved in the same version or older. When you open it, LV recompiles the binary code, so it doesn't matter which machine it originated from. If you want to compile an executable on a 32 bit machine and run it on a 64 bit one, I believe Windows handles that transparently. I'm not sure if the other way around is possible.

I don't like the backwards wire either, although when it's contained in a small area it's more managable. In the past, I suggested adding an option to split a feedback node in two (basically an SR without a loop). Maybe I should put it on the idea exchange. I tried the for loop idea a few years back and gave up on it, mainly because for loops can have multiple indexing sources, whereas a while loop with a T constant has become a de-facto standard for USRs, so seeing it immediately tells me it's a USR. Ultimately, as you said, it's a matter of personal taste.

In newer versions, you can also just use a feedback node without a loop.

Actually, that's not true. I'm doing this from memory, but there are basically two String classes - one is the string control class (which inherits from the Control class) and one is the string constant class (which inherits from the Constant class). Both of them have a property which returns the reference to the text part of the string. The text itself is a class which inherits from the Decoration class, if I remember correctly. As for the ring, the Ring class inherits from the Named Numeric class, but not all Named Numerics are rings (enums, for instance, are not. Not sure if there are others). The VI server class hierarchy is quite easy to view in LabVIEW (and reasonably logical). Just open the class browser or drop a property node, right click and select Select Class. That's correct. The KeyFocus property comes from the Control class, which is why I originally said it probably wouldn't work - because no one implemented it for the Constant class.

Yes, but the name and data type of the property have to match what you're wiring into it. I have no idea how many properties this applies to nor what will happen if the data type doesn't match. Once you type cast a reference, you're in uncharted waters. I remember doing this specifically on BD comments which had some of the text properties, but didn't expose them.

You would, because they're not related. I put type cast in bold in my original post to indicate that you should use the type cast primitive, which doesn't do the type checking (similar to the flatten-unflatten trick Felix used), but just reinterpets the data on the wire. As I also said, it was a long shot which didn't pay off.

You don't need to manually create the INI file. The package has two relevant VIs - the read VI (which you used in your example) and the write VI. If you wire your cluster into the write VI, an INI file with all the data will be created. When you want to load the data from the file, you wire the cluster into the input (like you did), which allows the VI to know what to look for in the file and how to build its variant output. You then wire the variant result and the cluster into the Variant to Data primitive and you have your cluster back. Now you can unbundle whatever you want out of it. What's nice about this is that you can later add elements to the cluster and the VI will still be able to load older INI files you saved (as long as you don't change the names of the controls in the cluster).

I thought the global tree crisis was when the leaf was adopted as legal tender (with apologies to Douglas Adams).

I was actually refering to the string control class (although, as I suspected, the KeyFocus property is not supported). You can highlight the comment using the relevant method, but that won't edit it.

I actually found one on the floor a couple of days ago in a pile of assorted junk I was cleaning up (presumably it fell there after my last trip to the states, the dates of which I would rather not disclose due to the fact that it will imply how long that pile of junk has actually been there . Let's just say that it was the beginning of the real estate crash, at the time when those bills were still around).

I'm guessing this won't work, but you could try to type cast the reference to the text control class. If the BD text class has the relevant properties and they're just hidden, this may work, but it's more likely not to work at all (and it even has the potential to cause damage).

Yeah, but Benjamin Franklin DOES actually have his own money.

I was thinking *groan*.

Quite easy, and in fact you don't even need the OpenG VIs, since you can just build an array of reference and then iterate over them and use the variant Value property flattened to a string. Then you just need a VI for saving and a VI for loading and you're set. Whenever you want to add a control, you just create a reference for it and add that to the array.