Visual Studio Error Codes

The computer communicates with the board via usb.


In the OP the plan was to put in place a dedicated line for the network cable.


So the Visual Studio code is middleware between the relay board (via USB) and the PLC (via network)?


Does the error cause the VS app to crash (so stop running, and needs to be restarted), or does WriteErrorLog(...) write something to the log and also stop the program while it puts up an error dialog box, and someone needs to check [OK] on that error log for the application to continue? I.e. what is the real problem here?
 
Last edited:
PC runs the VS application, and has a dedicated network leg to the PLC main switch.
The relay board is connected to the PC via USB as well as 2 other usb connected devices.

When the "error" occurs, a message box shows up stating the error, pressing the OK button will close message box.

20% of the time, pressing OK clears the error and the station continues.
80% of the time, the error returns and the PC has to be shut down and the station power cycled and then restart the PC and application.

Error still hasn't returned after the dedicated line was ran to the station, previous set up had this station daisy chaining the network through several stations/switches.

Like was mentioned in this string, we are starting to think this issue has been around forever as a bug in the code, but it wasn't "noticed" until I was able to clear up all the other issues.
This is currently the only issue I have with this assembly line, and big red circles get drawn around the notes about it..


The network leg COULD have solved the problem, but I've seen this issue disappear for several weeks just to spring back up and be the thorn of the day.

At this time, we have exhausted just about every option I can think of, and it is getting to the point the powers that be need to get the developer on the hook for it.
Have to wait to see if/when the issue comes back.

Good times =D
 
It seems unlikely that a different network cable on one "side" of the PC effects a change in the behavior of USB comms on the other side. Perhaps a timing/CPU/resource issue; we've all seen stranger than that.


Another XKCD classic (Hard Reboot; https://xkcd.com/1495/):



hard_reboot.png
 
Here is the error that is logged.

Error Occured In: Boolean StartRestartSwitch()
System.TimeoutException: The operation has timed out.
at NCD.AD8._Read8BitsValue()
at NCD.AD8.NCD.IAD8.Read8BitsValue(Byte channel)
at Test_Stand.RelayBoard.StartRestartSwitch() in C:\Test Stand\RelayBoard.vb:line 174


When I was troubleshooting this error in the beginning, I ask the developer why are we able to do the test in Manual Mode, but when we switch it back to Auto Mode (PLC Mode) we get the switches error.

The dev replied that in manual mode the system doesn't care what the PLC says, but in auto it does.
It didn't make sense to me, but now that there is a dedicated network cable and the issue has not come back, there could be something related to it.
 
Where is this PLC, and how is it related/connected? Is it querying the PC running this VB app? What protocol (Modbus/HTTP/custom API).



I still think the issue is unrelated to the network cable, unless the network connection, especially the daisy chain, is causing the system to hang, and even then the USB hardware should internally complete any communication with the relay board.


A timeout, which this is per the log, would normally be detected by the PC/VB when the relay board did not respond quickly enough. How frequently does the PC query the relay board i.e. how frequently is this StartRestart switch routine called? Is it on demand from the PLC via the network cable? Is it possible to increase the timeout value?


Real-time software like this, which running on a non-real-time platform, needs to be as robust as possible. If several real-time events need to happen, the system should be designed to isolate them so they can be asynchronous as possible e.g. the relay board should be queried at some sustainable rate and the value cached to a memory location, and the code that does that should be independent of the code that handles the network pull from the PLC, which latter code should instead look at the cached location. And all pieces should be able to detect failures and exceptions and recover/reset as gracefully as possible, along with making timestamped logs, both file-based and on-screen, to help diagnose when severe problems occur (e.g. someone knocks a cable loose). It seems like a start has been made along these lines with the Try/Catch and error log.



Caveat: the opinions above makes many assumptions about the process, when I actually know very little about it.
 

Similar Topics

I am having difficulty finding documentation or examples on integrating Visual Studio with iX Developer in order to develop custom objects...
Replies
0
Views
523
Hello, I am working on a project currently that uses a windows application on a PC to communicate with an NX1P2 controller to read and write...
Replies
2
Views
974
Hi I'm currently doing a college course in robotics and automation and a question we were asked was. A software application used by production...
Replies
10
Views
3,613
Hi All I have been switching between 2017 and 2019, all depending on which one i found more stable, at the moment I use 2019 I was just...
Replies
1
Views
1,459
Hi, I have an odd problem that consumes a lot of precious time. I will often lose contact with the TwinCAT System Service, and be completely...
Replies
1
Views
1,349
Back
Top Bottom