Unican ID address issue and fix

[Ausman]

HI all, I did something stupid yesterday.  Here's what I did and how I got out of it.

Due to covid I have been having to do constant changes to many of my client's systems, and nearly all of this is being done remotely.  I worked on a program that was for a 120 that is Unit 2 on a UniCan loop, with the "Master" a 130 at #1.   After the work, things weren't quite working as expected yet the ladder work looked ok.  Init and Reset didn't help.  So my (exceptionally stupid at the time)  brain thought it a great idea to download a blank program, Init and Reset, and start again. Literally milliseconds after I pressed the I&R button I realised my thinking error.........no more access to the 120!   Ooops.  Worse words were said.  Despair set in, as I didn't really have time for a 4 hour round trip.

During pondering/cursing/blahblah this for a while, I thought that I might be able to get into things again if I got one of the worker minions to change the Unit's ID in info mode.  It is totally against site rules for anyone to play with the controllers, but was worth a shot given the issue was part of the overall control process was now out of action.  I dug out a 120 to have on hand a guide to button pressing during a phone call.  Checked what I wanted to achieve and during this noticed that UniCan defaults into the 500K baudrate I use.  Hmmmm, thought self.   All I'm essentially getting them to do is change the Unit's ID.  I wonder if I can get into it remotely by changing ID in the comms area?

So I toddled back online to the 130 and using the "Get OPLC Information" button in the Communication-PC Setting control box, I found that the 120 was there as #1.  Huh?  The 130 is set as #1 and there's absolutely nothing in the 120.  Looked at things further and the 130 had shifted itself to #3, even though it hasn't had anything done to it at all.  With great hope I downloaded (using the different ID) to the 120 a blank program with just the UniCan Inits.  Init and Reset and all the unit numbers were still a bit strange.  Did an Init and Reset on the 130 and things were back to normal.  Downloaded the modified program that was the initial start of the issue and everything ended up working fine. 

Except my heart which gradually slowed up, and the bleeding from my forehead injuries where I'd banged it against the wall muttering "you stupid, stupid, stupid #$^#$!"

So it would seem that the creators have (perhaps inadvertently) allowed for humans to be dumbclucks, and it appears that the loop will rearrange itself if it thinks it needs to. During all of this work the "Get OPLC Information" button was crucial to ensuring I was talking to the right unit.

cheers, Aus

[kratmel]

It follows from your story - the legs are the main enemy of the brain. Anticipating a 4 hour walk, the brain found a solution.
The PLC developers had the same opinion and therefore made automatic address switching in case of a conflict.
Today I saw how remotely Unitronics support  can fix the Unistream brain and it also made an unforgettable impression on me.
The main thing is that as a result everything worked.
Therefore, I congratulate you on a reasonable solution to a complex remote task.

[Flex727]

It's tough to maintain a clear head in these situations. Nice going, @Ausman. Though I didn't have to think my way out of it, I had a similar heart-stopping situation once when I was remotely connecting to a PLC (on another continent no less so no chance of me being there personally). I was online with the PLC while it was in production and actively working when I accidentally hit the stop button in the online test box. I quickly realized what happened and hit run immediately. Fortunately, when in stop mode all outputs and other registers remain suspended without changing state. I got it back running again before enough had happened in the outside world to disrupt the PLC's current task and all was well, except for the adrenaline rush that surely took a few years off my life.