Thanks Rube, and Gerry
Rube,
I been programming mostly small projects for a little over 2 years. It wasn't until I joined my current company that I started to do alot of larger projects. Mostly programming several sections to larger projects. This form of state logic is useful because several different people can work on the same program at the same time. The only thing that needs to be added once everyone is done is the internal hand shakes from each file to file (i.e carriage needs to know when to push the product onto the hoist.) and yes its a type of high level bottle palletizer/row pusher. Mostly plastic bottles in the 1 gallon range. State logic does take some of the creativity out of it. I first learned of state logic while working at kodak. I took a full weeks worth of class put on by kodak mostly learning to draw state diagrams, then applying it to the actual logic. It was ok but for every latch you would have an unlatch. So it pretty much doubled the number or rungs.The person that taught me this is a former Kodak employee also. I also normally put a state diagram illustrating the current state the machine is in on the HMI/touchscreen. But even after training the operator still has no clue to what it means. When I see a problem I can normally pinpoint it to a section of the process then look up the state diagram for that section. Also Rube I am making a program right now for a similar machine. More of a freelance project I can send it to you when I am done along with the state diagram. As far as the part I showed you it works. The machine was installed and is now up and running without any problems.You would be suprised see how few problems there are with the code once its put into a machine Another thing that I like is I can pretty much do all of the symbols, addresses, descriptors in excel then import into RSLogix. When I actually start writting code everything is done its just a matter of selecting the write instructions, and symbols. I think this can only be done with RSLogix Pro.
Gerry,
Thats a good idea of putting a state diagram in the programming documentation. I myself could do without the input routing and the action logic(where the states actually drive an internal bit that which inturn drives a real world output. As for SFC's I disagree with you. Me and a former co-worker argued all the time I said SFC's where better. I think SFC's are great for a constant sequence where nothing differentiates. but "What If" the operator moves/jogs something manually or removes product from the machine etc. Maybe I don't fully grasp SFC's but doesnt it go from state 1, state 2, state 3 etc in a sequential operation. I thought SFC's could not go from a say state 2 back to state 1 or if its in state 3 it could go to state 5, 6 or 7. Maybe you could clear up the subject. I have only used it in Rockwells software. As for a continuous process I was thinking along the same lines as you are maybe
STATE 1- OFF/LOST
STATE 2- START/RUNNING(PROCESS LOOPS ACTIVE ETC)
STATE 3- IDLE
STATE 4- FAULT ROUTINE
anyhoo I should run
If anyone else has opinion's please express them both good and bad