ensegre
-
Posts
579 -
Joined
-
Last visited
-
Days Won
25
3 Followers
Recent Profile Visitors
69,079 profile views
ensegre's Achievements
-
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:
-
Serial Communication Question, Please
ensegre replied to jmltinc's topic in Remote Control, Monitoring and the Internet
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. -
Serial Communication Question, Please
ensegre replied to jmltinc's topic in Remote Control, Monitoring and the Internet
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. -
Serial Communication Question, Please
ensegre replied to jmltinc's topic in Remote Control, Monitoring and the Internet
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. -
Serial Communication Question, Please
ensegre replied to jmltinc's topic in Remote Control, Monitoring and the Internet
-
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
- 16 replies
-
- 1
-
-
- breakpoints
- wire values
- (and 2 more)
-
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?
