Jordan Kuehn

Just now, hooovahh said:

Funny you should mention that.  LAVA has created a new subforum dedicated to the LabVIEW Community edition, and this thread (among a couple others) have been moved into it.  Feel free to post questions comments, and information regarding the community edition there.  

Is LINX its own separate topic or should be co-mingled with LV CE? Thanks for the new space!

14 hours ago, Michael Aivaliotis said:

• LINX toolkit included with install. Supports:
  • Arduino via serial port.
  • Digilent uChip board
  • RasPi and Beaglebone Black as LabVIEW targets via Ethernet Port.
  • You can build/deploy a LVRT application on the above targets (RasPi and Beaglebone Black) and run headless. Exact same process as traditional NI embedded targets etc like cRIO.
  • You can use the LINX toolkit separately if you need it for commercial usage. Just install it on a non-community system. The license for LINX allows this now.

*Arduino is only serial support (not a target)

 

Is there a dedicated place for information and discussion about this? LabVIEWMakerHub is a bit sparse and I'm not sure it's completely up to date (mentions LV Home, etc.). I'm curious as to target support (RaspPi Compute 3?, Hats?, etc) and getting started. I have a RaspPi 3 and 4 on order as of last night. I'm very curious to see if this can fit a niche where a cRIO is overkill and $$, and I really need something like a USB-61xx in an embedded target.

7 minutes ago, Aristos Queue said:

I'm maybe perhaps just a little bit excited about this particular release.

What in particular has you excited? If you can share today. I didn't do the beta this year so I'm out of the loop on the new stuff.

19 hours ago, smithd said:

(real answer for me is that I use real-time, so 'next release' it might provide what I need but we shall see)

Same here.

Have you checked the Windows Event Log for any errors reported with the NIC during that time?

Whoa, this might be a game changer. I had written off RCF stuff years ago because of behavior like this. Just assumed I was screwing it up and continued on without it despite seeing lots of cool stuff available.

Honestly MQTT should have a native implementation for as much as NI has been hyping IIoT over the last years IMHO. 

I do get the overall point about making a case for GCentral though.

Given that it's not an actual file perhaps it has no idea of how much to read without parsing the lines in the primitive? There is no "size" information but if it reads as lines it keeps going until the end using read operations. Regardless -1 does not work on my 9046.

1 hour ago, Neil Pate said:

Tried that, no dice. The file read returns an empty string.

FWIW I just checked on a 9046 and same behavior as Neil.

Perhaps beginning to diverge from OP, but I've been spending some time with the RTI DDS toolkit. It does seem useful, but it also seems like the LabVIEW integration needs some improvement. Perhaps I'm not past the learning curve peak yet though. ViSci are you using it as more of a tag engine or are you using it for streaming and/or commands as well? It seems like implementation as a tag engine could get cumbersome on the BD publishing individual tags. Clusters work after using their tool, but that also seems cumbersome.

3 hours ago, ShaunR said:

That was my takeaway too (udp vs tcp). However. I've been working with LoRa recently (they just launched a couple of satellites) so my choices were MQTT or COAP to run on ESP8266 and ESP32s. I'm considering COAP mainly for the discovery aspect (which MQTT doesn't have but you can kind of make your own by having a topic to annouce to). The UDP aspect might come into its own if they enable UDP Multicast over the internet as standard though.

The auto discovery aspect is one appealing thing about the DDS package viSci was mentioning. However, from what I'm looking at I may still need to create some sort of announce topic like you mentioned using in MQTT to know what topics/keys are available. Does COAP provide a clean way of providing a list of all available pubs/topics/etc.? I haven't had a chance to look into that a lot yet. Also, are there LabVIEW toolkits for it? There are several MQTT toolkits, the shipping RTI DDS toolkit, and then back to the OP some 0mq and labbitmq available (not sure these all belong in the same list, but they are all in this thread).

29 minutes ago, viSci said:

It's not exactly native but the RTI DDS api has been included in the past few LabVIEW releases.

I've seen this mentioned a few times and it didn't make it onto my radar until recently. Have you had occasion to use it much in LabVIEW?

On 12/28/2019 at 11:50 AM, smithd said:

Its also just about 2020 and we don't have any secure network api built into the product.

That's also a very good point.

19 hours ago, smithd said:

I'm confused by this question -- there is an available zeromq library if that fits your needs. Its not perfect but its good, and its up to version 4.2.5 (current main lib release is 4.3.2).

If you don't need linuxrt support you can just use https://github.com/zeromq/netmq

As I read the OP the question was does zeromq fill this gap in native NI offerings? I quoted a mention of some of the holes that exist and suggest that I think they still exist. Perhaps I should add some context. I remember when this conversation first popped up as well as rabbitmq. I thought that it was just an effort to include a third-party communication protocol to make rt targets able to communicate with 3rd party devices and I don't really have *that* need. However, filling some of the holes in NI offerings is something I am interested in seeing if this is the case. I work with cRIOs daily and have a working toolset, but I was curious to see where this (or other) protocols sit today in terms of the original question. If I misunderstood the OP, my apologies, and I do realize this is an old thread, but that isn't always frowned on here.

On 11/27/2013 at 10:24 AM, M_P said:

I'm particularly looking into this (I'm also known as MattP on the NI forums, I work in the SE group like GoGators). From my perspective, it fills a gap that was partially filled by the AMC library (using same API for inter-loop and inter-node communication), network streams (automatic reconnect in background abstracted from the read/write, good performance), and shared variables (the pub-sub use case).  

 

What it handles better, IMHO, is that it handles not just the reconnect, but also the initial connect and intermediate send/receive queues entirely asynchronously.  It also easily handles N:1 or 1:N using several different transports.  It's not so much the base set of patterns that are useful, but the combinations of them that perrmit complex problems to be solved with very small quantities of efficient code.  Me likey.

Has there been any recent movement on this? Currently from NI I see a clunky method of flushing streams suggested for native messaging/command control, and the STM library and I don't really see anything that natively addresses the issues mentioned here.

I'm curious about the FLIR cameras. I've not had a chance to use them in an application, but they have always intrigued me. If you get your problem resolved (and I think Antoine gave some great advice) can you elaborate a little on the camera and perhaps the application?

On 10/5/2019 at 6:17 PM, Michael Aivaliotis said:

Can you describe the workflow? This doesn't seem to be a good solution on first blush.

Well, things have morphed a little and I may have been using some terms a bit freely. But for now I've been able to replicate the steps used in Google Authenticator for producing HMAC-based One-time Password algorithm (HOTP) with the help of this article as a starting point. There's still plenty to work through, but I was unable to find this available for LabVIEW anywhere. Perhaps I may be mistaken and there are some more fully developed libraries out there. I would love to see those!

The workflow is basically that an operator needs to get approval from an administrator to proceed with the sequence. Well, needs to be forced to get approval. A TFA implementation along the lines of what Shaun mentioned that could trigger the authentication process by an HTTP message to an existing service might be a way to use an authenticator app without a code. Obviously I'm no web developer. E.g. attempt to log onto a dummy google account with TFA set up and refuse to proceed until the service says that the authentication was successful. This would be dependent upon the pre-configured app on the supervisor's mobile device acknowledging the log-in, then LV would log back out. Perhaps the wrong hammer for this screw?

Agreed wholeheartedly. 

Has anyone dealt with integrating with 3rd party two factor authentication systems (e.g. Google Authenticator, Authy, Microsoft Authenticator)? I've searched around and found some information about Oauth 1.0a here but I'm not sure that is much help. 

The use case is an operator wanting to trigger an action that is approved by a supervisor on a mobile device. Offline authentication would be very helpful too.

2 hours ago, Rolf Kalbermatter said:

It's a named reference. You could think of it as a name and a pointer. There is an inherent mapping in it similar to other named references like VISA or DAQmx refnums. If you pass in a string, LabVIEW converts it automatically to a refnum by looking up the name in its internal registry for that refnum class. If you pass in a refnum whose internal "pointer" is a valid reference it will directly use that reference instead and save the intrinsic lookup in the refnum registry for the according class. (Class being here a refnum class not a LabVIEW class). 

Right. My point is that it is not intuitive to someone who is starting to work with NI Vision. Perhaps that has changed in recent years? I have seen so many people get confused why they branch the wire and perform image manipulation operations on it and wonder why the behavior is erratic for example. 

A good way to illustrate what the IMAQimage reference is. I really wish they had a better way to differentiate this on the wire. I've had to explain countless times that the wire is a reference not a value, but it just feels like it should be by value unlike other things that use reference wires.

1 hour ago, hooovahh said:

Oh for pete's sake! 

I use about as many four letter words each time I find Windows wants this stuff saved somewhere else or starts moving around user docs and such.

In what format do you have these signals? Array? Waveform? Dynamic Data Type? If the latter two, there are some fairly straightforward ways to re-sample and interpolate in the Signal Processing -> Signal Operation palette or the Express -> Signal Manipulation palette (Align and resample plus append signals perhaps).

It has been a hot mess with trying to get 2019 installed on my laptop. It killed all DAQmx support for 2018, but had options for the other version installed. Then wouldn't uninstall correctly and the NI website has simultaneously revamped ni.com/downloads making a standalone nearly impossible to find. Can we have ni.com/src back?

I believe if your word length is 16 bits and the integer word length is also 16 bits and mark unsigned you will have a FXP data type that will contain the UINT16 properly.