Unitronics download manager, and PLC download process best practices

[Fernando Castro]

1 hour ago, Ausman said:

Ok, I'm being dumb here and have probably lost some of the complete amount of info in the topamounts..

If reloading presets is an issue, but having them in the first place is essential to ultimate correct operation, why not initially run from all presets for just a few scans on the first boot with outputs locked off, then automatically stop things and reload stored parameters from file.  It might even be possible to have this all happen automatically, finally ending up with correct stuff.  But I think this will likely get back to you having odd numbers appearing.  I wonder if there's an easy way to singly  check all parameters against what they're meant to be in the stored ones, and doing any corrections that are needed.  It wouldn't take long for the plc to do this on its own, if it's possible.  Thinking cap time.......

cheers, Aus

part of the problem is upgrading software from plcs with a previous version of software, I can only modify future versions but I wanted to preserve some previous values (whitout messing up anything). I have a lot of systems that are essentially the same but designed to work with different combinations of hardware(which is a pain in the ass because of the many combinations possible, and specific values).

for newer versions of course I will load presets by software on power-on... My complain is that Unitronics has a check box  that alledgly does that, and there is a scenario on wich that  won't  work 😡 . 

I already had compiled and started to deploy the software by the time I discovered this...Now, it is just easier to double-check each parameter comparing to a picture, rater to take their risk of some preset being cleared if I try to use the backup method.

I have a tight timeline to deliver new versions of software and eventually I will have another chance to try some fancy way to automatically preserve settings for the next release, but to be honest I don't want other "surprises", and there are more important  features to keep working on.

I prefer to lose some parameters that can be added again from the HMI, rather than some weird thing in the background.

And now I finally understand why downloading a blank project fixes weird issues.

 

[Ausman]

32 minutes ago, Fernando Castro said:

to be honest I don't want other "surprises", and there are more important  features to keep working on.

I get that completely.

 

33 minutes ago, Fernando Castro said:

different combinations of hardware(which is a pain in the ass because of the many combinations possible, and specific values).

The different hardware trick I told you about a while back would likely help a lot here, but I understand it's a big undertaking to implement in your situation.  Perhaps in eventually changing things over you could get rid of presets completely and simply rely on the plc loading everything from the SD store on boot, which means it would be fully up to date.  Easy to say, hard to achieve on a big scale, likely worth it when you've got the time.

cheers, Aus

[Ausman]

As well....

1 hour ago, Fernando Castro said:

part of the problem is upgrading software from plcs with a previous version of software

To me this is the essence of your entire issue.  Somewhere in all of this process the way the information is being stored is affecting the data's structure.

[Fernando Castro]

10 hours ago, Ausman said:

I get that completely.

 

The different hardware trick I told you about a while back would likely help a lot here, but I understand it's a big undertaking to implement in your situation.  Perhaps in eventually changing things over you could get rid of presets completely and simply rely on the plc loading everything from the SD store on boot, which means it would be fully up to date.  Easy to say, hard to achieve on a big scale, likely worth it when you've got the time.

cheers, Aus

Oh, definitively it helps but by hardware, I mean other "devices" that interact with the PLC, as an example I have some sensors with different units and full-scale ranges even that are used for the same process variable, which means if sensor A is installed then I apply this LINEAR function, if B is installed then is this other LINEAR function. so if sensor A is installed a sensor B is selected on the screen then we have the wrong reading.

It is what it is... a very bad design. It went from concept to scaled production without fully standardizing.

Cables are built in-house which means 1 DB connector has 2 different I/O sets embedded in it. sensor A uses one set of pins, and sensor B uses another, so then the wires of the cable are crossed over and if you connect it on the wrong side you may fry something.

Part of my upgrade process is trying to use standardized and little by little replacing A/D signals with industrial protocols.
but of course, everything times 180 becomes expensive, so I won't be having fully standardized Hardware any time soon.

there are layers and layers of complexity that weren't necessary if we had stick to one single design😩.... But I get paid to handle all of this, so its a win for me I guess.