TimothyMoulder
Member
This program demonstrates an efficient (and spiffy) way to handle simple actuations involving two outputs and two inputs, such as a pnuematic cylinder with a bi-stable valve and two limit switches. Impress your friends!
The concept is simple - indirect addressing. By referencing the outputs and inputs using vector commands, you can actuate and monitor multiple movements (sequentially) using a single subroutine. To conserve memory, the position parameter data (which valves, which inputs, what faults to trigger, timeout duration) are stored in the database, and read out as needed.
DANGER NOTE!
Unitronics PLCs do not usually download database data at the time the program is downloaded. If you change the PLC DB structure (add or delete a row, column or table), the actual contents of the DB are reduced to gibberish, and you have to go into DB view and write the values back in. If you are using the DB to store IO parameters like I do here, this can get messy, fast.
Two ways to avoid this problem - synchronize your DB when downloading. I find this not terribly reliable - I've lost communications before on long synchs. The better approach is to make the column with your information in it "Part of Project". That specific data is secured against overwriting, and downloaded with the program every time, regardless of DB changes. This does consume project memory, though, so don't get too extravagant.
The real centerpiece here is the subroutine "000 Actuation 0". The rest is just support structure I tossed together to test the routine. It runs on a V280 with the newer OS on it, so you may need to update your OS to play with this.
What is simulated here is a two-cylinder pick-and-place, a so-called "grip & flip". It has manual functions, homing and cycling, and reports faults. The indicators on the button show the active inputs. The indicator on the cycle button shows cycle done. The indicator on the Home button shows In Ready (to cycle) Position. You must home it at least once before cycling, or it won't let you. Cycle, that is.
To the experts in the group - yeh, the support stuff is ugly, I coulda cleaned it up more, but whadda ya want for a few hours on a Wednesday morning as a simple experiment? If you find bugs, reply to the post and I'll fix 'em.
For the newbies to the field, if you look at the upper memory locations, you'll see how I arrange alot of my standard stuff I use in all my programs. Call it a freebie. But don't try to pass this off on your teacher as your own work. If you're lazy enough to cheat, you won't understand, and when he calls you on it, you're screwed.
TM
The concept is simple - indirect addressing. By referencing the outputs and inputs using vector commands, you can actuate and monitor multiple movements (sequentially) using a single subroutine. To conserve memory, the position parameter data (which valves, which inputs, what faults to trigger, timeout duration) are stored in the database, and read out as needed.
DANGER NOTE!
Unitronics PLCs do not usually download database data at the time the program is downloaded. If you change the PLC DB structure (add or delete a row, column or table), the actual contents of the DB are reduced to gibberish, and you have to go into DB view and write the values back in. If you are using the DB to store IO parameters like I do here, this can get messy, fast.
Two ways to avoid this problem - synchronize your DB when downloading. I find this not terribly reliable - I've lost communications before on long synchs. The better approach is to make the column with your information in it "Part of Project". That specific data is secured against overwriting, and downloaded with the program every time, regardless of DB changes. This does consume project memory, though, so don't get too extravagant.
The real centerpiece here is the subroutine "000 Actuation 0". The rest is just support structure I tossed together to test the routine. It runs on a V280 with the newer OS on it, so you may need to update your OS to play with this.
What is simulated here is a two-cylinder pick-and-place, a so-called "grip & flip". It has manual functions, homing and cycling, and reports faults. The indicators on the button show the active inputs. The indicator on the cycle button shows cycle done. The indicator on the Home button shows In Ready (to cycle) Position. You must home it at least once before cycling, or it won't let you. Cycle, that is.
To the experts in the group - yeh, the support stuff is ugly, I coulda cleaned it up more, but whadda ya want for a few hours on a Wednesday morning as a simple experiment? If you find bugs, reply to the post and I'll fix 'em.
For the newbies to the field, if you look at the upper memory locations, you'll see how I arrange alot of my standard stuff I use in all my programs. Call it a freebie. But don't try to pass this off on your teacher as your own work. If you're lazy enough to cheat, you won't understand, and when he calls you on it, you're screwed.
TM
