LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

enum's revert to int 16 when editing VI

Hi All

I've been editing a VI I inherited from a previous engineer. I had to change some enum types in this but when editing I'm having repeated problems with the connections reverting to int16 type and breaking more and more connections. I get a little red dot on shift registers in the while statements, and on broken VI's.

 

Any pointers I could use

 

Regards Doug

0 Kudos
Message 1 of 8
(2,349 Views)

An enum cannot be an I16.  Are these actually rings?

 

Enums should be type definitions.  This way you only have to make the change in the ctl file and all instances get updated.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 8
(2,333 Views)

You will have to excuse my knowledge level, I've programmed for about 20 years but I'm new to LabView. I have a typedef enum which is a control vi, this is wired to various nodes in the diagram I have in front of me. I have been trying to change this enum for a new one I have created. When I am correcting the wiring in the diagram I have the wires keep reverting to (unsigned word [16-bit interger (0 to 65535)])" which is the base type of standard enums afaik. This whole thing is in a while(case(case)) nest with the enum controlling the state machines.

 

I assume something I connect to is the problem however I have not been able to discover what yet (I'm now 2 days in).

 

I would have thought this would be relatively straightforward.

 

Regards Doug

0 Kudos
Message 3 of 8
(2,329 Views)

How have you been trying to change this enum for a new one? Are you replacing the control typedef, or the instances on the block diagram? Which version of LabVIEW are you using? Do you see this happen if you use the control typedef in a new VI, or just this one in particular? If you can, it would help if you uploaded the code so we can better see what you're doing. It almost sounds like one of your cases has a different data type wired to the output tunnel.

0 Kudos
Message 4 of 8
(2,325 Views)

Is the control VI really a typedef (not just a control) and do all instances of the enum have the link to the type-def (Auto-Update from Type Def.) enabled?

There must be conflicting data types wired to the case tunnel, so in at least one of the cases there is a different enum or a plain U16.

 

Message 5 of 8
(2,322 Views)

Are you creating the new enums by right-clicking on the tunnels and clicking "create constant".  That could be the issue.  I would copy an instance of your type def and paste it instead.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 8
(2,318 Views)

smercurio - Verion 12.0f1 32bit - new VI's are fine. I have 'REPLACE'ed the typedef in the diagram.

I have created a new typedef for what I'm doing, as we need the original for other VI's.

Dan_u - not sure, I'll have a look at this.

crosrulz -I'm copying the typedefs not creating constants.

 

Background

The diagram is big, its a test framework a previous engineer wrote. We load sub VI's dynamically into the framework to perform production testing. This dynamic loading is what I am trying currently to fix, and the original typedef is used by all the test sub VI's hence not wanting to change this. the new typedef just contains create and destroy cases.

0 Kudos
Message 7 of 8
(2,305 Views)

Found the little blighter. just one incorrect typedef, thanks for all the help

0 Kudos
Message 8 of 8
(2,299 Views)