LabView 2020

[Colinvellacott]

Thank you Rolf.

So where does this leave me?

I assume I am stuck and will just have to support two versions of LabView?

[bbelley]

Hey Rolf,

Totally makes sense what you say. I think the thing I think about is they made such an effort to release 2020 community so to not support it, which LINX is a big part, is odd. I think there is miscommunication.  Also there are some simple free things they could do, like stop pointing us to makerhub if the boards are inactive. Point everyone to these boards. I think that alone could get this NI LINX board more active. I spent a good month of posting two or three items before realizing I had to look elsewhere for help. Others may just give up.  That could help keep our LINX base strong at least. Also who has control of the server for makerforum? Because it is a big miscommunication when NI says they ship with LINX and then makerforum says the website (and LINX??) is deprecated. Did someone get upset like a moderator put that on the website after getting upset or what is going on? I will try to get in touch with the latest guard at makerhub because I really don’t want to see this awesome toolset die.

[rolfk]

---

@Colinvellacott wrote:

Thank you Rolf.

So where does this leave me?

I assume I am stuck and will just have to support two versions of LabView?

---

Actually the best approach would be to actually debug the software and at least report what exactly happens, where and in which VI if you can't come up with a fix yourself. The current Linx library unfotunately has the nasty feature to pretty map any returned error code from the Linx  library calls into the super unuseful 5003 "something has gone wrong" error in the LabVIEW VI side. That's not very helpful. Knowing in which VI things go wrong and what the actual Linx error code is, if any, will often already help further.

Since the entire Linx toolkit is fully open source, expecting a user to do some debugging themselves should be not a to extreme request for now.

[Colinvellacott]

The problem occurs with the with the VI example supplied with Labview. Did you not say that you were able to recreate the same fault as me?

[Colinvellacott]

I've just looked at NI Max again and the Arduino does show up as Com1

[rolfk]

---

@Colinvellacott wrote:

The problem occurs with the with the VI example supplied with Labview. Did you not say that you were able to recreate the same fault as me?

---

No, I didn't say that. I use still the original LabVIEW 2014 + Linx install for my Raspberry Pi, and don't have an Arduino ready (but I also have a Beaglebone Black although I didn't test that yet). My current hobby project is to improve the shared library for Linx that runs on Raspberry Pi and Beaglebone Black to be more modular and also support dynamic devices such as UART, I2C, or SPI that are not standard enabled on these boards but can be enabled in the startup configuration for these controllers. It should also be fairly easily reusable for other similar devices like the RockPi and such.

Also my Linx shared library is intended to move all of the handling for serial, TCP/IP and native access to the shared library part and make the LabVIEW side of it a very simple wrapper around it. Once that works, I intend to test it also with the remote interface mode that is normally used for Arduino type devices, but that is somewhat in the future.

[Colinvellacott]

sorry  I thought this meant that you had...

"

K, I was able to reproduce your error code 5003 like in your screenshot on page 1 of this forum subject.  I used a genuine arduino mega 2560 R3 loaded with the LINX firmware wizard using labview 2020 version 20.0 32 bit community for windows 10, digilent LINX version x.x.x (unknown version, since JKI VI Package Manager says I have not installed the latest, which is 3.0.1.192), NI LabVIEW LINX Toolkit version 1.0.0.9 is apparently also not released.  I will install 3.0.1.192 and see if this error goes away."

[rolfk]

Well, aside from the version chaos, which is a bit unfortunate, I would like to know where exactly this error occures. What function is called, where and how and what is the underlaying error code that Linx so unhelpfully converts into the catch all 5003 error?

[bbelley]

---

@rolfk wrote:

Well, aside from the version chaos, which is a bit unfortunate, I would like to know where exactly this error occures. What function is called, where and how and what is the underlaying error code that Linx so unhelpfully converts into the catch all 5003 error?

---

I can help there also. I can recreate his error, so I can maybe open up some sub VIs and chase down where this is happening...

[bbelley]

Ok I have more info for this bug.  It appears to happen in the Initialize Device VI, however when I open that VI's block panel and step thru with Highlight Execution the error goes away.... which indicates to me it is a timing issue... maybe something is not getting enough time to stabilize something.... I will dig in more and see how I can fix it.  When the error does not happen in HE mode, then I am able to blink the digital pin high low as expected and then close the program.