ensegre

So I have been given this monster FPGA project to patch. The main target VI is a monster with a BD of 9034x10913px, with 72 different loops . Yes there is some documentation an comments, but that does not really cut it. The logic uses I haven't counted how many tens or hundreds of different FIFOs and memory locations, read and written by this or that loop of the hyerarchy. Why, Why, don't I have a"Find all instances" for FIFOs , like there is for VIs, to navigate them?

Maybe the question is if you have to be committed to this array of clusters of string+variant for some specific reason, or if it is an attempt to implement some architecture which might have a different implementation. I.e., I don't understand if yours is a general question about design, or a specific question about the mechanics of converting variants to data.

Looking at the example of the OP, it looks he's already aware of typedefs. To him to say what exactly he meant.

I must admit that I may have misunderstood what the OP wants to do, hence my answer may have been completely off. Is he rather trying to construct an array of heterogeneous elements, by flattening all his possible data types into a variant?

A malleable VI may be neater, but it's a matter of taste. Something along the lines of this:

i.e. crossover cable vs. null modem cable. But the OP says that the exe succeeds with the command, so that doesn't seem to be the issue here.

Just to make sure - if you read 5 bytes, you get the first 5 bytes. If you increase the number to 'byte count', you would get a timeout warning if the other program really outputs only 5 bytes, but you would see the trailing ones, if there were. Also, right-click the string indicator, check 'Hex display' may come handy.

Can't say without seeing the rig's documentation (if at all good) and some amount of trial and error. These old devices may be quirky when it comes to response times (the internal uP has to interpret and to effect the command) and protocol requirements. Are you sure the message does not require an EOT or a checksum of some sort? Does the rig respond with some kind of ACK or error, which you could read back? Are you sure of your BCD encoding? Wikipedia lists so many flavours of it: https://en.wikipedia.org/wiki/Binary-coded_decimal If there are read commands, returning a known value, like the current frequency or the radio model, I would start with them, to make sure that the handshake works as expected.

This is the situation in 14 and 19 here. In 14 Wire has some interesting properties in 14, but not Value. Note that e.g. Attach Probe is accessed as a property in 14 and a Method in 19; and BD is an array of integers in 14.

Rolf is correct, I forgot to enable scripting in the LV19 I used to check OTOH, in LV14 "Block diagram" is indeed present but is an array of I6 rather than a ref. I can't guess what was its intended use back then, maybe it was just an uncooked feature.

Since you asked, here are my findings: LV23 - can create the attached snippet (don't know if it works), and save it for LV14 (also attached). All the pulldown menues show relevant properties LV21 and LV 19 - open the saved for LV14, show a correct image, but the first property node lacks the "Block Diagram" entry in the pulldown; further properties have no menu ETA - and show the relevant pulldown menues when "Show VI scripting" is checked. LV14 - the first property node menu *has* a "Block Diagram" entry, but the further properties don't match LV23 W14.vi W23.vi

I thought it had to be read as in "the *top level node* of the BD of that particular instance", not as "the BD of the Top (prototype) VI", but haven't really tried... How do you get the values running onto a wire, btw, for my education?

I assumed that if you obtain externally the clone VI ref and just pass it to the VI Block Diagram property you get the clone block diagram ref, but I haven't really tried it. Isn't that the case? If so, sorry for misleading you...

There was this thing about getting the VI ref of the actual clone instance; I remember that in the past I asked about that (it must be somewhere here on Lava), and besides, there is this nice Vi commander tool (forgot its name, windows only) which obviously uses it. Once I have a moment of time I'll look for it and report. ETA: , of course!

A bit sad to have to say this nowadays that most of the traffic on this forum is about leaked videos, money rituals and human sacrifices, but isn't this the part where someone starts to repost links to basic LabVIEW training resources on the NI site?

My 2c: I guess that the problem with an expiration date on an offline computer is that you have no means for the executable to verify that they didn't set the clock backwards to extend indefinitely their usage. If you don't expect them to be pro hackers, what about protection by simple obfuscation? E.g. the incremental time the program has run, saved periodically in obfuscated form in an essential key file, masked as "configuration"? With some mechanism to make more complicate to get through just by rewriting an older file in place of it?

No pb for me as well, neither today nor past times I consulted it. But all together I'm on it quite seldom.

Coming back to report. Scavenging the net I've found essentially three set of connectors between Redis and LV: what can be downloaded from https://forums.ni.com/t5/Example-Code/REDIS-database-LabVIEW-toolkit/tac-p/3508611 taking into account the corrections listed in the thread. This seems to be the more widespread, considering even that it was shown as an option at the CERN LV user group this year (see https://indico.cern.ch/event/1388470/contributions/5911487/attachments/2843544/4971934/lugm_LabVIEW_at_CERN.pdf, slide 22). Dates originally to 2014. Nick Folse's https://github.com/tauterra/Redis-Client-for-LabVIEW of about three years ago, according to its author no further developed. Found a couple of flaws, easily corrected. https://github.com/Bas-vE/LV-Redis , which claims to be an evolution of 1., promoted to LVOOP. Most recent of the three. The philosophy of the three toolboxes differs somewhat from one to the other, the first one being more of the kind "one VI for each Redis command", the others putting perhaps more the accent on the transaction protocol than on the completeness of the commands implemented. Redis's huge command set also expanded during the years in question. However, I found in all three something which looks to me a bit of a no brainer, which is that TCP client connection are opened and then closed for each elementary operation. While that might have a minor performance impact, I found that the approach prevents Redis' MULTI pipelining. I have forked 1. in https://github.com/EastEriq/redis-in-labview and 2. in https://github.com/EastEriq/Redis-Client-for-LabVIEW for dwelving into. Finally, I have resolved for adopting my fork and augmentation of 1. in my project, but only after I modified it so that TCP connections can be kept open throughout the client sessions.

IIUC the OP, s/he put an AI node (which has a variable execution time) sequenced with a fixed delay inside a while loop, and then complains that the while loop is not repeating itself at 1/delay time. OTOH s/he says that s/he doesn't really need the AI. I'd answer here that, complexity permitting, since this is a deterministic target, the delay should be concurrent with the code executing in variable time, and that it should be longer than that execution time of the variable part. Then one iteration of the while loop would be guaranteed to take exactly as long as the delay. Another option, if memory doesn't fail me, could be a SCTL tied to a secondary time reference, running at a submultiple of the master clock. If the complexity of the code doesn't allow execution within the prescribed timing, the compiler will then complain. Can't say about the actual case, but often complex code can be simplified by factoring out, or by pipelining.

AFAIR, from my very limited experience with a single model of FPGA, AI and AO conversions may take a long, variable number of clock cycles (dependent on routing perhaps, of the order of several tens of cycles), and therefore cannot sit in a SCTL. Don't take me literally though, I might be wrong and that may not be true for all FPGA boards.

ah, and when you're mentioning two computers - connected how? Is there some network gear along the way, which filters packets and blocks connections on unauthorized ports?

Sounds like on your computer port 45321 is already in use by some process (not necessarily labview). Besides, 45321 is still in the IANA range, whereas 58411 is already in the Dynamic range. https://stackoverflow.com/questions/133879/how-should-one-go-about-choosing-a-default-tcp-ip-port-for-a-new-service https://www.baeldung.com/cs/default-port-network-service On top of that, you may have lingering.

Tools/Profile/Show buffer allocations...