Selecting between two I/O refnums not allowed

[cbutcher]

It would be nice if this code:

Case Structure version

could be replaced by this code:

Select version

but doing so gives an edit-time error specifying that "Select: Possiblity of Dynamic Refnum not supported for current target".

Is there a fundamental reason this can't be allowed? The behaviour is presumably the same in each case, and the references are from the same place in both cases. In the case structure, the exact same references that are passed to the Select node are used, with the same True/False choice.

It's not a huge issue, but it would be a nice usability/readability improvement.

[Intaris]

I'm torn.

Implementing this brings along baggage regarding loops / case outputs.

I personally like the fact that LabVIEW FPGA forces me to stay int he hardware frame of mind when programming (as opposed to suuggesting that hardware references are things which even exist when executing code).

YMMV.

[cbutcher]

Does LabVIEW FPGA force you to stay in the hardware frame of mind?

Although of course you're right that we have to consider the cost of various operations, or the fact that some things must be specified in advance (as here, kind of... but not really), it seems like this particular case is logically simpler (i.e. boolean switches two lines, compared with any valid case input switches in principle any number of lines - although that would be very ugly).

Can you expand on the "baggage regarding loops/case outputs"? I think I've probably not understood what you meant. I suspect you mean that outputs of a loop might become more 'dynamic', which then needs to be handled (/rejected by compiler?). However, in this case, I'm only considering inputs. Are you suggesting that I could also (not on FPGA) write the code as follows? (VISA References used for convenience, true case shown in duplicate below, but obviously the point is they're the same case structure)

Edit for clarity: and that this would make them loop/case outputs...

[Intaris]

Not all cases are binary choices. Many are controlled by an integer index. The picture you show in pretty much identical to your select example.

Would you then expect it to work for objects?

[cbutcher]

Sorry - the picture was supposed to be identical. I was trying to identify if that was what you meant about outputs from cases and loops.

In the case of multiple Case Structure cases, the same is true, but you can't use a Select anymore - on "normal" LabVIEW we might have an array of references and use Index Array - on FPGA we have N identical cases with just a different value unbundled (if we wanted a cluster on desktop, we could use Cluster to Array or similar).

Both of these situations assume that all of the references are suitably compatible - i.e. the same type, or on FPGA that they have the same available operations.

My idea here is just relating to the simplication of reading/writing identical code - as you identify, it can be done with a Case Structure, and so I'd like it to be possible without a Case Structure.

In the case of Index Array and an array of references, there are additional complications due to the possibility of manipulating the entries to the array, out of bounds accesses, etc (although given fixed size on FPGA, perhaps a little easier to check) so I can see why that might not be a good idea / might be significantly harder to correctly implement and therefore isn't worth the effort. Obviously it would be nice to have it, but I recognise it's likely a harder problem.

In the case of the example given here, Select is a very simple replacement for a 2 case Case Structure, in which each case performs the same action. The same input (boolean) produces the same output (unbundle a reference, use in an I/O Node).

As to objects, sure - that'd be nice. However, I think that requires what's already suggested in a different idea relating to increased capabilities of Dynamic Dispatch on FPGA - Run Time Dynamic Dispatch Support.

I wrote that then decided it probably isn't true. For objects of the same type, I guess this could be ok. It would require knowledge that the object type is the same (if they have different types in a hierarchy, I suppose it carries out a different operation, which would require different compilation, if I understand correctly). However, the compiler already has knowledge of the static item types and as far as I know, doesn't allow the object types to be dynamic.

[Intaris]

AFAIK, LabVIEW applies the same logic to handling objects as it does with references.  That's exactly my point.

It makes debugging a real PITA when running in simulation mode.  How would you place a probe on this code when running in simulation mode?