I assumed (gosh, I hate that word) that you were asking about more than just the "tuning" values ...
here's the quick easy answer ...
if you set the RSLogix5000 PID up to use the "Dependent Gains" equation, then yes, the "tuning" values SHOULD (I repeat SHOULD) be the same ...
BUT ...
note that the RSLogix5000 PID also provides an "Independent Gains" equation as its default setting – so don't forget to make that all important setup change or your tuning settings for Integral and for Derivative will certainly NOT be the same ...
going further ...
when converting from RSLogix500 to RSLogix5000, you can't just "drop the PID into place" and use the same existing rung programming ... for starters:
your RSLogix500 PID was probably (well, it should have been) programmed on an UNconditional rung – since it has a built-in timer to "trigger" it into execution ... on the other hand, the RSLogix5000 PID does NOT have a built-in timer – so you'll have to take care of the triggering with external programming ...
but ...
the RSLogix500 PID also has a built-in "STI" setting – which would allow it to be triggered EXTERNALLY by executing it in an STI (Selectable Timed Interrupt) file ... at this point, we have ZERO idea of how you had the original (RSLogix500) PID programmed – so we can't tell you whether or not the same "triggering" techniques will work with the new (RSLogix5000) PID - (by placing it in a Periodic task for example) ...
and ...
many people leave their RSLogix500 "STI/Timed" setting at the default of "STI" – and INcorrectly do not use an STI approach to executing the PID – which means that it calculates a new value on EACH scan through the program ... in that case, the old "time sensitive" settings for Integral and for Derivative will definitely have been "skewed" by a very large factor (as a means of compensating for the improperly timed/triggered execution) ...
so ...
if that's the case, then your Integral and Derivative settings for the new RSLogix5000 PID will definitely NOT be the same – since the new processor will probably execute its program MANY times faster ...
going further ...
the RSLogix500 PID doesn't have an internal method of handling MANUAL operation (for bypassing the PID's "automatic mode" calculations by an operator's setting) ... on the other hand, the RSLogix5000 PID has two built-in methods ... so if you're already using some type of "manual" operation scheme – then it will certainly need to be handled (programmed) differently in the new platform ...
going further ...
the PID for the RSLogix500 system SHOULD have been scaled for an input of 0 to 16383 to give optimum operation ... specifically, there is no internal "scaling" available with that platform ...
but ...
the PID for the RSLogix5000 system DOES use an internal means of "scaling" (for both input and output signals) so you'll have to make some critically-important adjustments in that department ...
going further:
there are other differences - related to Bias vs. Feed Forward; the Tieback feature; etc. ...
but ...
we can't properly advise you there until we know which RSLogix500 platform you're making the conversion from ... specifically, some RSLogix500 hardware platforms use a standard INTEGER file for their PID control structure – but others use a newer PD-type file ... the layout (and therefore the nuts-and-bolts "rung" programming) would be different in some instances ...
so ...
if you just want to know: "Can I simply plug in the same tuning values?" then the BASIC answer is "yes" ...
BUT (and this is the tricky part) ...
that basic answer will ONLY be correct IF (big IF) the external (rung-type) programming was correctly done for the original RSLogix500 PID ...
AND (big AND) ...
the external (rung-type) programming happens to be correctly done for the new RSLogix5000 PID ...
AND (another big AND) ...
if the internal settings of the new RSLogix5000 PID are correctly done ...
and keep in mind that many of these newer "internal" settings don't even exist in the older PID setup ...
so ...
did you just want to know about reusing the original "tuning" values? ... or were you asking for advice on the practical "nuts-and-bolts" type issues which are involved in this sort of conversion? ...
