Why does data type change if "increment" function added?

[WNM]

I have a state machine with a shift register coupling data between states. In an early state I connect an I32 constant to the data path which causes the data path to take on an I32 type. In a later state I insert an increment (+1) function and the data path changes to a DOUBLE type. Why? I can insert an I32 conversion before or after the +1 function and the data path remains or is converted back to I32 type.

[WNM]

Unfortunately I could not find an way to attach this file while posting the question so here now is an example of what I am talking about.

[Shan Pin Koh]

A quick sidenote:
You should always initialize your shift register.

To fix your problem, right click on your shift register and select "Representation". Then select I32.

I've attached your code with the integer initialized.

Hope that helps.

Shan Pin Koh

[WNM]

I'd have to disagree with your comment "You should always initialize your shift register." There are definite times in LabVIEW where you want to start with an uninitialized shift register! Admittedly for this simple example that is not the case and what you suggest will work but there are other times it will not. I want to know why the increment function can take a wire that appears to be defined to the system as I32 and change it to a different data type...

[Shan Pin Koh]

It is good programming practice to initialize your variables, be that in C/C++, VB, etc. Likewise, the reason I say you should always initialize your shift register is so that when your VI runs, you know that it starts at your initialized value and not something else.

There will be times when your shift register will start at a previously defined value and you get intermittent problems. It's similar to creating data dependencies in LabVIEW. It's not required but it's good programming practice to have some form of dataflow, be that for troubleshooting or debugging. And yes, there are times (not a whole lot), where you cannot create data dependencies but at times like this, you'll need to make sure you can safely say, I am very sure that this VI wi
ll run before this VI will. Likewise, by initializing a shift register, I can safely say that my loop will always start with 0.

Sorry but I get defensive at times... Gorka is right about how the data type changes. You can changet the data type by changing the representation by right clicking on the shift register.

Shan Pin Koh

[WNM]

I know you mean well and you are trying to extend what you have learned in other programming languages to LabVIEW but in this case you are wrong. Those of us that have been using LabVIEW since the early days know that uninitialized shift registers (USRs) are LabVIEW's way of implementing something akin to C/C++'s static local variable. Back before LabVIEW had explicit constructs for Global Variables, USRs in dedicated vis were the recommended way of providing global-variable functionality (and in some cases still are!). Search NI's site for the string "uninitialized shift register" (use the quotes). One of the references you find says this: "There is an alternative method for storing global data, and that is to use an uninitialized shift re
gister. Essentially, if you do not wire an initial value, a shift register remembers its value from call to call." They certainly are used a lot in the older example vi that NI makes available. You are missing out on a useful LabVIEW construct if you refuse to use USR's!

[dkaron@conceptsnrec.nospam.com]

It looks like the default type for the increment (+1) VI is dbl.
You can force the wire type to I32 a number of ways.
If you cannot tolerate initializing the shift register outside of the loop, how about inserting a
"convert to I32" in front of the increment?
another thing would be to create an I32 typed increment VI and use that instead.
Cheers
Dave

"Warren Massey" wrote in message news:506500000005000000272F0000-991728092000@quiq.com...
> I'd have to disagree with your comment "You should always initialize
> your shift register." There are definite times in LabVIEW where you
> want to start with an uninitialized shift register! Admittedly for
> this simple example that is not the case and what you suggest
will
> work but there are other times it will not. I want to know why the
> increment function can take a wire that appears to be defined to the
> system as I32 and change it to a different data type...

[Gorka Larrea]

Unfortunately i couldn't open your example, i only have LV 5.0, but at least in this version, if you put an add, the data type changes to DBL until you wire another I32 to the second add terminal, i suppose this is done because if you add a I32 with the default numeric, DBL, you'll have a DBL, so type changes, but once you add a I32 with another I32, everything works as you want.
Hope this helps

[WNM]

Yes, with the "ADD" function the data type of the other input to the function can take precidence and change the output type. But the original question concerns the "INCREMENT" function which has only one input.

[Brian_Vibert]

I find it odd that it is converted to a double, maybe a bug? You will definately have occasions where you do not want initialize the shift register as previously posted.

You can add a convert to I32 function after the increment function and it will change back to I32. This function can be found in Numeric>>Conversion.

See attached...

Brian