Unity Pro XL "AUTOTUNE" function

I'm a Siemens guys switching to Schneider/modicon stuff.

There are two pieces of equipment they used to run independently but they've reconfigured them so that one feeds into the other. I was tasked with installing a new sensor for the level of one feeder and should turn the first crusher and its belts on when the second is low. No big deal. Got that part working.

When I downloaded the project and got up and running the AUTOTUNE functions started throwing an error "128". If I count the bits out and we start at 0 that means bit 6 is true. The help files "helpfully" skip bits 5 and 6. So no idea there.

EDIT: I just realized that 1111 1111 is 256 and 1000 0000 is 128. So bit 7 is high. And it's error is this: "The thresholds pv_inf and pv_sup of the controller to be set are identical". But I don't think they are because I set the cold and warm setup.

I downloaded and looked at the autotune example from Schneider, but it didn't seem to make a difference.

So these are my questions:
1. Anyone know what might be going on? I can attach a screenshot and mark out variable names and such.
2. How in the heck do I look at actual run-time values in a struct/para in Unity? Or get to a specific DFB instance?
3. How do I convince my boss to switch to Allen Bradley or Siemens?

I figured it out.

Unity apparently isn't very strict on the whole input/output thing when it comes to user function blocks or library blocks. There's an output "PARA_C" that is used mostly as an input. It does modify one value and I guess uses the rest as static variables. I think that means it should be an in/out, but whatever.

I also finally found how to look at the actual value of structs. You right click->"Initialize Animation Table".

Because that screams "variable"...
Right.

Still no idea how to get to user DFB instances at run-time.

right click on the DFB instance and choose "refine" to view inside the block.

no experience with autotune sorry

V0N_hydro said:

right click on the DFB instance and choose "refine" to view inside the block.

no experience with autotune sorry

Click to expand...

That's it. Makes troubleshooting easier if you can trace a value from screen to output/input.

Thanks, Hydro.

Unity is good. Give it a chance.. you'll find your way around. Another thing to be careful of is when doing a download, you will wipe out variable values or they will go back to whatever you had set in the variable definition. There's an option for saving and restoring data to and from the PLC, on the PLC menu. Use that before and after. Learnt that the hard way on a big plant with several hundred setpoints...

You should be able to do "most" things using online edits. Use that where possible.

Don't get me wrong, I was mostly joking. Even though I'm used to Siemens, it would take more effort to switch the whole plant than learning Unity's quirks. Besides, all PLCs seem to be "6 of one and a half-dozen of the other", so to speak.

My only complaints are these.
1. Unity tried to shoehorn OOP on a system that was never meant to handle it. Leads to a weird program layout with no clear execution structure. It works, but why not allow us to program in Java too?
2. Unity almost requires you to edit online without testing which is dangerous. They already stuck the round OOP peg in the square hole, why not shove in modern testing procedures too? When the program is live is not the time to figure out that "and" should have been an "and-not" and now you can't shut down the 500-ton piece of equipment before it crashes into the deck. (Yes, I've done that before...). I'd really like to be able to edit offline, test in the simulator, then deploy without issues.
3. Finally, the help file is extremely verbose and yet still manages to leave out important details.

It's still better than Step 7 in every way but those 3. Even Siemens gave up on Step 7. I was just being cranky cause I had been working on the problem off and on for a week.

75% of my experience is on Unity, the rest AB and unitronics, so I am definitely used to Unity, but I prefer it *for the projects I am doing*. I can see for larger distributed applications I might prefer AB, but I also haven't looked in to M580 remote IO.

I don't really see how being able to make structs or DFBs is shoehorned OO. It all fits pretty well and naturally to me, much better than function block does in RSLogix. in FB for things that must be executed before or after another block you can chain them together with the Enable input and output, or I just place it lower down and make a comment.

I also change the dimensions of the FBD sections so they are tall and not as wide. We will make comments the width of the screen to separate parts of the FBD section so it is almost like a series of ladder rungs.

If some logic is really sequential, ST or ladder might be a better fit than FBD.

Do any other PLC vendors have modern testing infrastructure?

If you are modifying the program online make a flag that you can enable / disable to turn on or off the new code paths. How would you do it differently on Siemens?

If you are making big changes to a machine that is already running you are going to run in to issues making on-line changes no matter what brand you use. I guess AB lets you 'test online edits' and quickly stop testing them, but that seemed pretty loose to me, anything I'm downloading to the running process I am pretty damn sure is correct, otherwise I test offline on the model.

The simulator is really good. You can take your project, edit it offline, switch to simulation mode, run the tests, and then go back to the saved version from before switching to simulation mode and download that.

I program a model of all the equipment in to the PLC program and use the FORCE_BIT block to make the inputs respond appropriately to the outputs and then I can run the logic and catch all the silly sign errors etc. I also program the whole control system with all of the PLCs and remote IO etc powered up and talking to eachother just like they will in the finished product.

We might do a rebuild all on a project once every 2-3 years, we generally never stop the PLC.

Unity is my preferred platform but I also recall not liking it initially.

Siemens is just more structured I guess. It not a huge deal, but the track record for doing full downloads in unity with me is 0%. I have to fix stuff every time. That precludes testing offline. For me anyway. On Siemens I could write offline in a temporary project, test with the simulator, then merge code into the online project after testing. That seems to require a full rebuild and download on Unity.

I'm sure Unity can do that too, not sure how though.

I'm not upset with unity. I think I'm just getting old and not liking the whole change thing. Lol.

downrangefuture said:

Siemens is just more structured I guess. It not a huge deal, but the track record for doing full downloads in unity with me is 0%. I have to fix stuff every time. That precludes testing offline. For me anyway. On Siemens I could write offline in a temporary project, test with the simulator, then merge code into the online project after testing. That seems to require a full rebuild and download on Unity.

I'm sure Unity can do that too, not sure how though.

I'm not upset with unity. I think I'm just getting old and not liking the whole change thing. Lol.

Click to expand...

You can do it also on Unity, it is not as straight forward as on Siemens.
1. Make copy of original project
2. Make all changes to new project and test with simulator. (different version than original)
3. When you have simulated new program, make export of modified sections and blocks.
4. On origanl project, go online and import all sections and DFB blocks at online.
5. make online build.

There is also Unity Diff (seperate program), which shows all differences between two Unity projects.