Error 1 occurred at an unidentified location

[Prx_Dave]

Good morning,

I've gotten the error shown in the screen capture below on a few occasions now.  It started occurring when I began running two different experiments from the same CompactRIO hardware.  I have a single target which scales all of the data, does alarm checks and writes the data to network shared variables.  Two separate host vi's generate graphs and log data to separate text files.  Previously I had one target vi and one host vi running just one experiment.  Besides the fact that this error is completely nondescript, I don't see how adding a second host vi (plus some additional code to the target vi) could cause this issue.  This will occur at random times when no changes have been made, so I'm not sure how an input parameter can suddenly become invalid if nothing has changed.  I'm unsure if the target vi pauses when this error occurs, but I know from my datalog files that when this error occurs both host vi's do nothing until I click continue.  So far every time this has happened I've clicked continue just once and everything ran normally again for several hours (or days) until I got the error again.  Any thoughts/suggestions would be appreciated.

Dave

[PatJamSim]

Hello Dave,

Unfortunately, due to the nondescript nature of the error, it is extremely difficult to comment on what could be causing it.  My first thought is that both hosts are pulling information from the same location, and a race condition exists that only manifests itself occasionally.  That is, if the hosts are alternately grabbing data, you will be alright as long as data is available.  However, if they attempt to grab data and it doesn't exist because the other host already grabbed it, an error could be thrown.  Are your hosts both running the same VI?  Do they access data from the same locations?  Do you use any local variables, which can lead to race conditions?

It would definitely be helpful to try and pin down where the error is occurring.  To do so might present some difficulties.  You could create a subVI that logs error messages along with information on what function just executed, and place this subVI at various key locations in your code.  Then, when the error is thrown, you could go into the error logs to narrow down where the error was coming from, and debug that portion of the code to ensure no invalid or empty characters are in use.  Remember that an empty string could cause an invalid character; for example, if both hosts were looking in the same location, one would find data and remove it while the other finds nothing.

If the error itself is not causing any negative behavior, then you could introduce error handling code that would check error conditions and remove the Error 1 before it was thrown.  This would allow your code to continue running after the error was thrown.  However, since you are not aware of the source of the error, it may not be the best idea to simply ignore the error indefinitely, as it could eventually manifest itself into a worse error.

I'm afraid I can't offer much more insight without more information on your code, what it is doing, how it is written, and how the hosts are interacting with the target.  Hopefully you have made some progress in narrowing down the cause and debugging your code.

[Prx_Dave]

Thank you for the response Patrick.  Upon continued troubleshooting since my post (and your response) I believe I've determined where the error is coming from.  I have a sub vi that communicates via RS 485 to the heater controllers on both systems.  The heater controllers are all daisy chained to a single RS 485 port and I use a for loop with a 100ms delay to address each controller individually.  I use network shared variables to send setpoints to this sub vi from the two different host vi's.  I believe that the problem lies here.  Also, fyi, the sub vi outputs a single array of data (also a network shared variable) which both host vi's scan and grab the data they want.  I don't believe that two vi's reading data from the same variable is an issue because I've done that many times.  When I originally created the sub vi, I added code that would send setpoints of zero if either of the network shared variables are empty as I anticipted a potential error.  Since the error is so general I didn't immediately think this was the problem, but I temporarily disabled the sub vi and haven't had an error in 4 days.

What I'm trying to determine now is whether this is definitely the issue and if so, how I can send setpoints from two different vi's without causing errors.  Again, any ideas would be appreciated.

Thanks,

Dave

[PatJamSim]

Hello Dave,

It sounds like that set-point subVI is the culprit.  It is possible that adding a second host caused the subVI to no longer receive set points properly, and this subVI then attempted to communicate without having proper data, resulting in the Error 1 - invalid input parameter.  You should look into how you handle the set points from each host.  Are they writing to the same locations?  Does the correction for empty shared variables to be set to zero work properly, or are invalid values still present in the shared variables?  Is it possible that the subVI is receiving the necessary data but not sending it out properly?  You have most likely already gone through and asked yourself many of the same questions, and have hopefully made some progress working with that specific subVI.

After doing some digging, I couldn't find any information saying that you can't write into shared variables from multiple locations.  Network streams limit you to one writer-one reader functionality, but shared variables should not.  Are your shared variables RT FIFO enabled, and what data type are the variables that are causing you problems?  Are you writing into the same shared variables from both hosts?  If so, then why do you need to write from both into the same locations?

One work around that you might consider would be to have one host send its setpoints to the second host, then compile all the setpoints on that host, and write them as necessary from a single location.  While it doesn't appear that writing from multiple places is causing the error in and of itself, it wouldn't hurt to see if writing the exact same data from one location allows you to bypass the error.

If it's possible, then posting your subVI here would be helpful.  It does appear from your previous post that this subVI is where the error is originating.