martinav (Customer) asked a question.
I am trying to make my basically working program to work better. There are a few things about it that arent 100% right. I am thinking the basic structure needs some help. Here are the current top issues. Note, I will update this as I go through this. I am trying to look at this in bite-sized chunks so I dont overwhelm the audience with my atrocious program.
- Valve control - Basically works, but sometimes, they dont switch on/off exactly when I need them too.
- Status LEDs on my HMI. Some work, some dont. I'm certain control bits are in the right places, but they dont always work. Sometimes yes, sometimes no.
These two items seem to be basically the same situation. I am heavily using stage programming. My set/rst are being controlled for my valve operation and my HMI using MCx bits. My valve controls are in a single stage in MAIN. While, LED control are spread throughtout stages in a program. Valve control is much more accurate than LEDs. For LEDs, I have a bit for blinking and a bit for solid on. So, thre are set/rst throught the stages in my program.
So, my question is this. Should I break out the rungs for my valve control into its own program, which scans constantly? Even throw in the LED control, and use C bits to set/rst the MC bits?
Or, better ideas. Yes, I am a flounder.
Thank you.
Valve control rungs in MAIN:
Should I structure my LED MCx bits in a similar manner as above, and have them in their own program, or with the valve controls?? Cbits on the left??
I am still paranoid about giving it too much to do at once. Since I have yet to find a performance limit. I already have a constantly running rs232 program to scan pressure every second. If I keep throwing constantly looping programs in this thing, when will I begin to see some performance drop? Is there something to look for if this happens? Or, is there so much headroom that I'm worried for nothing?
Since your question is around program structure, it's good to understand how the PLC works.
I hope this helps.
Are you possibly over using Stage as modularization, not sequencing? What do your stage diagrams look like (yes, draw them out on a piece of paper) - does the control of your Valve and Status LEDs make sense from a Stage diagramming standpoint?
DirectLOGIC CPUs only have 1 code block, so people would use Stages as "code blocks". That's not what Stage is for. For example, monitoring alarms needs to be constantly monitored - every scan. Stick it in its own code-block (MonitorAlarms), not in a Stage in $Main. Have $Main RUN MonitorAlarms, which never ends. That's not to say you can't have something similar in a Stage program that constantly runs that you used SGSET to enable immediately. But if most of your "logic" is in a stage that is huge with lots of complex logic - that's not stage. That's a code-block crammed into a stage.
Draw out your stage diagram - does it make sense. You can have sub-stage diagrams within a single code-block if it makes sense logically (e.g. SG S10 thru S19 is a mini stage diagram that handles Modbus comm sequencing with a specific slave). You COULD have that in its own program code-block, or not. But if it's a bunch of complex ladder logic where the differentiation between stages is not obvious (e.g. things aren't switching on and off when you need them), it's not right at the Stage level - let alone the Ladder Rung level. Hard to fix low level logic if the high level logic is not right to begin with (now you're chasing symptoms and making spaghetti code).
Yea its time for a block diagram. I'll throw one together and post.
Yea... I know.. that should have happened first!
I did have a scope written at least. So, I had the basic premise and flow understood.