Everyday a new bug when working with RT targets

[qedded]

I am frustrated working with RT targets. I experience everyday new bugs and unexpected behaviour. I have to reinstall my hosts and targets periodically, otherwise I can't deploy my projects anymore. Is it just me or do you experience the same?

[GerdW]

Hi qedded,

---

@qedded wrote:

Is it just me or do you experience the same?

---

IMHO it's you.

I never had this problem over several years with several different cRIO targets…

[rolfk]

---

@qedded wrote:

Is it just me or do you experience the same?

---

It’s a bit of a flamebait question, but you asked for it. 😁

No, I work with cRIO regularly and can’t say I run into trouble on a daily base. Not even close. Things can get weird at times and a regular reinstallation of everything whenever my computer is ready for replacement (about every 3 years) is normal and sometimes I wipe it in between to get a clean slate, but usually not.

I do have a few particular things though:

- I stopped installing multiple LabVIEW versions on the same system and use normally a VM for each version. Normally one or at most two LabVIEW versions on the same system.

- I'm very conservative in upgrading LabVIEW versions. My current main development system is 2020, with a few projects in 2018 because of old cRIO hardware that isn't supported in newer versions, and for general Open Source tools I tend to work in 8.6 (but also have a 7.0 installation on that VM for some archeological tests).

- While I do have other engineering software on the computer, this is usually on the actual hardware and not inside any of the LabVIEW development VMs, except for TwinCAT where that is needed to interface from LabVIEW to Beckhoff systems. But for pure data communication between the two I often use direct ADS communication on LabVIEW native TCP nodes and don't really need TwinCAT itself for that.

[Worle]

I have a feeling you have asked this question before. A couple of weeks ago there was a very similar question (I have a feeling word for word) to this which I wrote a pretty detailed response to detailing some common issues and resolutions (All easy when you know the answers)

The entire post was deleted though...

[GerdW]

Hi Worle,

---

@Worle wrote:

I have a feeling …

The entire post was deleted though...

---

In the last days/weeks there's a lot of SPAM.

Once we get the very same question in the next hours (or days) I usually merge the threads and notify the moderators…

(The OP username seems to indicate another SPAM account. Let's wait for responses or other new users with the same question.)

[rolfk]

---

@Worle wrote:

I have a feeling you have asked this question before. A couple of weeks ago there was a very similar question

---

I can't remember that post, it was summer vacation and I wasn't regularly online, but the question certainly sounds baity and like a post being scraped from some other more generic discussion forum to create a legitimately sounding post. I can only guess about the motivation but it may be part of creating a legitimate looking account to eventually go full spam anyhow or simply someone wanting to test his flame retardant protective suit. 😀

Most often though those accounts seem to get forgotten by the person (or bot) creating them and just use up server space.

[Intaris]

---

@GerdW wrote:

Hi qedded,

---

@qedded wrote:

Is it just me or do you experience the same?

---

IMHO it's you.

I never had this problem over several years with several different cRIO targets…

---

In my less humble opinion, no it's not just him.

I've been having problems with deploying to RT targets for many years, have made many posts about it and have been in touch with NI about it. There are also several people on the forum reporting similar things. Obviously not everyone is affected, but for us, we really have the feeling sometimes we're spending as much time working around bugs as we are actually programming.

There are multiple issues at play in our problems, some may apply in this case.

1. Compile cache gets invalidated but the compiler doesn't pick up on it. This leads to code NOT being deployed when it should actually be deployed because it HAS changed, but the IDE doesn't realise. This leads to the IDE executing old code on the RT while the IDE has the "NEW" version. Whenever this happens, there's a mis-match between the VI supposedly being run and the VI actually being run. Fun addition: quickest way to quit LabVIEW is to add a probe in a VI that is supposed to be running but isn't. Also, multiple levels of Inlined VIs cause havoc with this. We have established, through forced trial and error, to save any changed inlined VI and it's parents all the waysa up to the top-level VI (After forcing a random change in source, breaking and unbreaking the VI in order to force a new compile) in order before even trying to compile.

2. Typedef propagation is lacking. We regularly have problems with changes in typedefs being propagated properly. We change (for example) an FPGA reference - new bitfile) and the reference does not get properly propagated. We often have to (within a single VI) delete multiple wires and then simply reconnect them in order to get the correct FPGA reference type to be used.

3. We have had issues with drivers. We had an issue where reading from a DMA  FIFO from a FPGA target when the FIFO is empty would actually prevent the target from rebooting when performing a soft boot. Those two actions seem completely unrelated and it took us more than a week of searching and debugging to trick it down. It was made even harder to locate as it only happened when the RT controller was forced to use a single code. At least for this one, NI did eventually manage to issue a patch and seem to have corrected it for later software versions.

4. We even had a case where LV was obviously taking information from the compile cache to OVERRIDE local code. We had a very obvious case once where a typedef suddenly had a format of an old typedef which hadn't been used int eh software for 3 years. As it turns out, there was an entry in the compile cache for the VI at that path and it very clearly took that information over the version actually in the source code of the VI. We picked up on this because it led to broken VIs, but how many other instances of this are there. How can the compile cache EVER override a local source code? Questions upon questions.....

When you say "Every day a new bug", I think it's a couple of core bugs which lead to an array of different outcomes. The compile cache is a classic. Whenever we have unexplainable weird behaviour on RT, we either clear the compile cache (which has a lot of awkward side-effects for all other targets and projects) or we simply copy the repository to a newly created folder on disk as this also causes the compile cache to be recreated. IT also, unfortunately, causes the compile cache to continually grow in size.