Sign in to follow this  
Followers 0
Spedley

Help Required With Strange Jumping And Pid

19 posts in this topic

I don't know how best to describe this without posting the program, which isn't mine to post. My knowledge of the machine is not complete but I would like to quote for any modifications to it's operation so I'm checking in advance that I know how the machine does it's present task. It is a large heated press for forming composite parts. There are 4 heaters in the tool, each of which have independent control. My problem is regarding the PID instructions and the strange flow of the program. This is the basic structure of the program. I have just shown the PID and JSR instructions. '...' indicates more code. FILE:2 FILE:3 FILE:4 FILE:5 FILE:6 JSR 4 PID N11 PID N12 PID N13 PID N14 JSR 5 ... ... ... ... JSR 6 JSR 4 JSR 5 JSR 6 JSR 3 ... As you can see the flow of the program is complicated but simplified it is this: File 4 > 5 > 6 > 5 > 6 > 6 > 3 > 4 > 5 > 6 > 2 What I want to know is how this will affect the PID instructions. Each heater appears to be independent and does not reference any other. As far as I can tell this is a programming error but I'd be very interested if there is actually a reason for it?

Share this post


Link to post
Share on other sites
I would definately say it is a bad practice. Are there any conditional statements before the JSRs?

Share this post


Link to post
Share on other sites
Greetings Spedley, some questions for you: (1) is this a PLC-5 or an SLC/MicroLogix system? ... (2) if it’s a PLC-5, how are the PID rungs “triggered”? ... (usually this is done with a timer’s Done bit) ... (3) if it’s an SLC/MicroLogix, are the PIDs’ “Time Mode” settings set up for “STI” or for “Timed”? ... (4) I’d have more questions if you were using the PD-type data files - but since you’ve told us that you’re using the N-type, then we don’t need to go there ... the best answer I can give you at this point: in general terms, IF (big IF) everything else is set up correctly, then your weird scan sequence shouldn’t cause any problems ... basic idea: it doesn’t matter how many times you execute the SAME PID instruction during a single scan, as long as the PV, SP, etc. all stay the same ... look at it this way: the first execution of the PID “sees” a certain amount of error - and calculates a certain value for the CV ... now suppose that the same PID is executed again on the same scan ... this time it still “sees” the same certain amount of error - and calculates the same certain value for the CV ... in effect, the output won’t change during the scan ... said another way: “same-thing-in-same-thing-out-same-thing-in-same-thing-out” ... now let’s go beyond “basic ideas” ... in a PLC-5 system, the analog signals PV and CV are usually moved into and out-of the processor by way of Block Transfer Read and Block Transfer Write instructions ... secret handshake: these “communications” type instructions operate “asynchronously” to the ladder logic scan ... in simple terms, this means that we don’t know at exactly what point in the ladder logic scan these instructions will actually move their data into or out-of the processor’s data files ... specifically, these “asynchronous” instructions do not necessarily happen “right-now-before-we-leave-this-rung” the same way that normal “synchronous” instructions do ... and so ... if you’re working with a PLC-5 system, then it is entirely possible for the first execution of a PID to “see” one value for the PV ... and for the next execution of the same PID to “see” a different value for the PV ... this COULD cause two DIFFERENT values of CV to be sent out in rapid succession ... now in actual practice, I sincerely doubt that there would be a great enough difference between one value of the CV and the next to affect the operation of your system ... but ... you asked a question ... I’ve tried to provide an answer ... I fully understand your reluctance to post your program ... but on the other hand, we’re sort of looking through a keyhole here ... if you can post more information, we’ll try to give you a more detailed answer ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Ron - One question for you. What would be the advantage of this JSR layout?

Share this post


Link to post
Share on other sites
none that I can image ... I'm guessing that the original programmer just didn't know any better ... or that somewhere along the line, one programmer's work was modified by someone else ... and the weird jumping sequence was never really noticed until now ... of course I can't see the program, so I'm really just guessing ... but as for "why?" ... I haven't been able to come up with anything reasonable ... edit ... possible guess: maybe (big MAYBE) the block transfers are located in some of those files ... maybe there was an effort to make sure that the PID was always looking at the "latest and greatest" input data for the PV ... some programmers go to great lengths to try to insure this type of operation ... in my personal opinion, in most cases that's a lot more trouble than it's worth ... basic idea: suppose that you're not executing the PID while you're waiting around for the latest and greatest input signal to arrive ... question: what the heck are you sending for a CV signal during the pause? ... usual answer: the field output is still being driven at the value of the last CV ... my next question: so how does waiting for the "latest and greatest" PV help anything? ... specifically, why not just go ahead and calculate the output for THIS trigger event based on the old stale PV and get on with your life? ... Edited by Ron Beaufort

Share this post


Link to post
Share on other sites
Ok, thanks. I was just curious. I have seen it occasionally in programs and figured it was just a mistake but didn't know if there could be a reason. One thing I do use multilple JSRs to the same routine for is event logging or some common code that needs to be executed under many different conditions. That is the only reason I can think of using it for. That is why I asked if the JSRs were unconditional or not

Share this post


Link to post
Share on other sites
Thanks Ron, I realised last night that I hadn't said which PLC I was using! Sorry for that. This program (or vairants of it) is running in 7 machines ( 3 SLC503's and 4 SLC504's ) and it is using timed mode. for the PID instruction. Although I have no objection to posting the program it is not mine to post, however I don't think posting one of the heater files will cause any problems. There is no analogue output card and hence PID instruction seems like overkill to me. It looks like the programmer is using the PID output to 'predict' when to turn the heater on or off. MOULD_PRESS_1.pdf

Share this post


Link to post
Share on other sites
excellent point ... we need more information ...

Share this post


Link to post
Share on other sites
lastest thoughts based on Spedley's posted code ... ok ... now we can discount the “PLC-5 Block Transfer” line of reasoning ... and the “Timed” setting would be the logical/correct way to go ... unfortunately I don’t have time to go through this in detail right now ... (bo$$ has work for me to do today) ... but I’ll try to take a look at it in the next day or two ... you guys will probably have it all sorted out by then ... just off the top of my head, it looks like the PID is being used (as you suggested) only to do some basic calculations ... for example: are we at setpoint? ... etc. ... I sincerely doubt (based on what I can see) that the extra JSR jumping is serving any useful purpose ... just a thought ... if it’s SAFE to do so, I’d think about temporarily disabling those “extra” JSR rungs and see what happens ... I’d be willing to bet (pocket change only) that everything would continue to work just fine without all of that confusing back-and-forth jumping ...

Share this post


Link to post
Share on other sites
I don't think I'de bet more than that on any program I hadn't seen!I am now certain the extra jumping is a 'mistake', however I'm not very familiar with PID operation. What I do know is that a subtle change to a PID (i.e. running it twice per scan) could (potentially) create a very different output !

Share this post


Link to post
Share on other sites
I've been reading the manual regarding SLC's and the PID instruction and it would appear that the code I've posted is copied from there !

Share this post


Link to post
Share on other sites
With the JSRs like that? Can you refer me to the mainual your are talking about and the page?

Share this post


Link to post
Share on other sites
Sorry, not with the JSR's like that - I'm sure they are an error, but the PID control of a digital output is in the manual - it's not how I'd do it but thats another story.http://literature.rockwellautomation.com/i...um013_-en-p.pdf Page 207 (9-31)

Share this post


Link to post
Share on other sites
Ok, I was going to be really confused if Rockwell was putting examples in there book with JSRs like that

Share this post


Link to post
Share on other sites
Greetings Spedley, regarding your statement: I notice that you wisely left yourself some slack (with that "potentially" disclaimer) but just for kicks, let's work through a quick example ... I've attached a simple program with a "dummy" PID on the first rung ... I manually set the PV for 7000 ... and the SP for 8000 ... the Kc setting was for 1.00 ... the Ti setting was for 1.00 ... and (most important!) the "Time Mode" was set for "TIMED" ... then I copied-and-pasted the same PID onto 9 additional rungs ... I placed a conditional rung with a TND (Temporary End) instruction right after the first PID ... so that by toggling the conditional bit (B3/0) I could easily execute or NOT execute the "extra" PID rungs ... then I started the program and let the PID react as shown in the first part of the graph ... this portion of the trend shows what happens when we execute the PID only ONCE during each scan ... then, about halfway through the trend, I toggled the TND rung and started executing the nine "extra" PIDs ... notice that the trend shows that there was no difference in the CV (output) even though we were now executing the same PID a total of TEN TIMES during each scan ... now, as near as I can tell, this really doesn't have anything to do with the "extra" JSR rungs in your program ... but I thought that the topic was sort of interesting so I decided to run the experiment and post the results ... maybe this will come in handy for someone else down the road ... and one more question for you: does your program use any IIM (Immediate Input w/Mask) instructions? ... I'm still trying to come up with some reason why the original programmer used those extra JSRs ... I'll admit though, I'm rapidly running out of straws at which to grasp ... MANYPIDS.pdf

Share this post


Link to post
Share on other sites
No, there are no immediate I/O scans. From the look of it the programmer was not familiar with AB (there are lots of nested branches instead of extended branches) and I guess he wrote the program in a logical fashion, i.e. heater one calls heater two etc but then found out how Allen-Bradley handles subroutines and just never took the JSR's back out. Thanks for your experiments! I realise the Timed mode (hence the DN bit) will just ignore any further PID instructions until the required time interval has elapsed. AB reccomend this time interval be at least 10 program scans which would mean that two PID's would never be 'live' in the same scan. The PID data I posted indicates a 0.02(second?) Loop Update (and from S:22 the maximum scan time is 20ms) - perhaps something to watch out for there! Also, the input he's using (1746-NT4) is set to be 'scaled for PID' and the PID's Smax is 825 and Smin -210. Does this means it's being scaled twice? I may recommend getting rid of the PID because I thinks it's overkill and probably inefficient (e.g. the tool only need to hot every 4 minutes - it may be worth turning the heater off at the end of a cycle)

Share this post


Link to post
Share on other sites
One caution about turning the heaters off. Most electric heater, especially cartridge type heater, fail during the process of heating the material up and not during the process of maintaining the heat. Unless there is some tremendous electricity cost savings I would leave the heaters on. Since I have not actually seen the program, one other thing. Make sure that your heater ON set point and your heater OFF set point are spread far enough apart to keep whatever is turning the heater on and off from chattering too much. The further apart you can spread these the better, of course there comes a point that you will have too much temperature deviation for the process.

Share this post


Link to post
Share on other sites
I thought would probably be the case but some of the heaters are inductive so they should be ok, and also the tools are large lumps of aluminium so I doubt they would cool more than 10% per cycle. I don't know any facts and figures yet other than there are 7 machines with 4 banks of 50 inductive heaters (or equivalent). 7*4*50 is 1400. I don't know what each inductive heater is rated at but I expect the costs are high.

Share this post


Link to post
Share on other sites
If you don't mind me asking, what is the problem they are having with the heater. Are they having a high failure rate, component problems with what is firing the heaters....?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0