Real-time enum typecast

[Intaris]

I've recently started working with Real-time systems (like a week) and one curious piece of behaviour I've come accross is the extremely lengthy time required for a simple enum typecast.  I've read elsewhere why this is (due to flatten and unflatten to ensure data integrity) but it just seems crazy to have to forgo using an enum for my state maching on RT (having to mentally map integer values to states becomes tiring) for this reason.

Does anyone have any other ideas on this?  Anyone run into the same problem?  Our loops are running at significantly under 0.1ms loop-time and a single typecast to enum is throwing a huge spanner into the works.

<begin mad rambling>

I was wondering if there would be the possibility of having an editor-only typecast option.  I would love to be able to tell the IDE to treat the value as an Enum but let the executing code NOT actually do the typecast.  Of course this would require binary matching between data types but for, say I16 to I16 enum this should work OK.  Another option would be to have a "type" input for a case structure to allow the DISPLAY of the cases be re-cast to a given data type.  The changes occur only within the IDE  This could be useful for enums, char to u8 and so on.

<end mad rambling>

Shane.

[Ben]

OK I'll fess up.

I never tried to type cast on a RT system.

I have used enums without noticing an issue.

Is function overloading involved?

Sorry but that is all I can say.

Ben

[Intaris]

Hi Ben,

Using enums themselves is OK on RT as long as you don't try to typecast an U16 to an U16 enum.  This takes AGES.

I currently have a workaround that I'm generating an array of all enum values sequentially (gets constant folded) and then using the input parameter to fish out the correct enum value and passing this to the case structure.  This is IMMENSELY faster than a typecast.

Regrading function overloading.... what do you mean?

Shane

[Ben]

---

@Intaris wrote:

Hi Ben,

Using enums themselves is OK on RT as long as you don't try to typecast an U16 to an U16 enum.  This takes AGES.

I currently have a workaround that I'm generating an array of all enum values sequentially (gets constant folded) and then using the input parameter to fish out the correct enum value and passing this to the case structure.  This is IMMENSELY faster than a typecast.

Regrading function overloading.... what do you mean?

Shane

---

That was just a guess at what type of situation would require type casting in RT.

Take care,

Ben

[tst]

Another option - create a subVI with a U16 input and your enum as the output and simply connect them with a wire. I have no idea what the performance characteristics for this would be under RT (e.g. can you meaningfully inline it), but it's cleaner code.

[Kevin_Price]

No good ideas, just raw spitballing.  Have you tried different ways of wiring the typecast type, i.e., constant typedef, constant strict typedef, local variable, dummy control? 

-Kevin P

[Intaris]

We're in the situation that we're even trying to avoid sub-VIs to get max speed.  The Software is LV 8.5, so no inlining there.

Might be ultimately the best choice though, even if it is slower than my current method.

Shane.

[Ben]

---

@Intaris wrote:

We're in the situation that we're even trying to avoid sub-VIs to get max speed.  The Software is LV 8.5, so no inlining there.

Might be ultimately the best choice though, even if it is slower than my current method.

Shane.

---

Well if you are at that point...

The extra connectors on the icon connector introduce additional sub-VI call time.

if memory serves they were on the order of picoseconds.

Ben

[Kevin_Price]

Aside from the small static memory hit and aesthetic inelegance, your method of indexing a constant-folded array seems pretty tough to beat.  If the tiny further run-time gains you can make using plain integers as magic numbers for your state machine actually make an appreciable difference, I'd be inclined to say you're operating much too close to your margins to feel good about the system anyway.  Food for thought (from someone who doesn't have to live with any of the consequences...)

-Kevin P

[Intaris]

Again, it's not the use of enums per se but the conversion which causes trouble.

One example os a sub-vi which hosts a tiered state machine for instrument control.  It's a moderately complex VI and takes about 0.4us to run an iteration.  The enum type cast would be used in here and with this type cast the run time increases to about 0.7us.  This is a completely unacceptable performance degradation for some editing comfort.

Hence the ugly workaround.  We're running quite a lot of code in our 100us control loop and every bit helps.  There are more and more features being added all the time so how effecient we write the code determines which customer gets the bad news of "Sorry, we can't implement that".

Shane