If I change the structure of a class, can I download the instances one at a time? I have a fear that downloading one instance of the class will update the class structure in the controller, affecting all the instances. Is that true?
Here is bone-head move that I made. I took the the advice of the books on line and promoted a function block parameter up to the module level. below is the example in the books on line. I did the same thing, but with the PV.
The problem I'm having is that we set the parameter type to "Internal Reference", thinking that it's a parameter showing an internal value.
We'll, we're getting a module level "Output Transfer Error", that I assume is due to the link trying to push a floating point value into an Internal Reference parameter type. The error has been ignored for a while and is not causing any problems at the moment, but I wanted to correct this. I figure I could either delete the link, or change the parameter type. I figure deleting the link would be the easiest.
Thank you,
Frank Jr.
Frank,
The Class structure is not downloaded to the controller. in fact, if you were to compare the download script of a class based module, or stand alone module with the same design, they would be identical. The Class is used by the database to manage the structure of the module's in the database, but when it comes time to download, each module is compiled into a download script individually. This is why you can change the class and download affected modules one at a time. You should change the Class and perform you downloads as needed. I would not recommend to create a Class and convert the modules to the new class. This is unnecessary.
A Linked Composite is different. The Composite block is downloaded to the controller, and referencing modules use this instance. All modules are affected when this composite is downloaded. In this case, to change the composite and download modules one at a time, you would need to create a new composite, and edit each module to refernece the new composite. If you used the composite in a Class, you'll need to create a new class as Otto suggests.
When a parameter is defined as an internal reference, it acts as a pointer to the referenced parameter. You can read and write through this referenced directly with an expression, or you can wire to it in the module diagram. The INput or OUTput format of the parameter dictates the flow of data when you wire, but an expression can read and/or write. However, you should not write with an exression if the output parameter is wired. The order of execution in the module will determine which value wins.
In your case, if you wired the AI/PV to '/OUTPUT', and defined OUTPUT to reference AI/PV, you have an illegal reference. As Carl explains you can simply remove the wired connect, or chagne the parameter to a Float with Status. I would recommend removing the wire. The wire and Float parameter add CPU and memory load because the AI/PV value is transferred every scan of the module. The Internal reference does not hold the value, and is simply a pointer to the PV. Not a big deal, but cummulatively, this can add up. Also, the act of writing to the Float parameter with a wire sets the exception flag on the parameter, forcing it to update across the network making this a periodic rather than exception reporting. If the source parameter's change flag is not set, but you wire it to the Float parameter, the float parameter will treat the write as a change. With a reference, the AI/PV change flag determines if the value should be communicated.
For ease of trouble shooting, the wired connection is much clearer, so I use them when data flow is important. For promoting parameters to the module level, say as communciation parameters, I prefer the internal references for efficiency, as these are not part of the control loop.
Another difference with internal reference parameters is you cannot upload them. If you create a parameter called GAIN at the module level, and reference it to the PID1/GAIN parameter, you can change the gain of the PID in either location. However if you change the MODULE/GAIN parameter, and attempt to upload it, the Upload utility will not be able to insert the value into the database at this location. More useful might be the SP parameter, which is changed by the Operator, and we never want to upload it. Using an internal reference parameter, we can provide the access to PID1/SP to the operator (DetlaV Security allows Operator to write to this parameter name), but as an internal reference MODULE/SP cannot be uploaded by accident.
If you wired MODULE/SP (configured as FLOAT with STATUS) to PID1/SP, writes to PID1/SP would always be overwritten by the MODULE/SP parmaeter and uploading the MODULE/SP would work.
External references to modules in the same controller work the same as Internal references (Direct pointers to the data source). Modules in remote controllers go through the comm layer, so the reference is direct to the Proxy Client parameter, but writes can take up to 200 ms to be transferred to the destination, where they are written to the parameter location.
Andre Dicaire