Messaging Multiple PF40 for Parameter Storage

i am after some advice just to get me on the most suitable path, for the best (slickest) way to achieve this....

i am wanting to be able to store all the parameters for the drives in the PLC and if a drive goes down, swap it out and then download that settings to the drive, but also the ability to call them from the drive to display them and edit and redownload the ones that had been changed.

i have created a UDT with all the parameters, i just want alittle advice on which is the best route to go down with regards the messaging style, i am wanting to put all this into an AOI to duplicate on multiple machines.

anyway here is what i am thinking so far...

i was thinking of either using one message instruction and changing the path to whichever ethernet address i am after, and then having seperate message instructions for each parameter and sending them sequencially using the DN bit from the previous message to set the next message.

or a message instruction for each drive and then one instruction per drive for the read parameter and one per drive for the right parameter and sequence through them until all of them have been transfered.

Rob

Rob, I think you could do all the parameters from all the drives with one message instruction.

Looking at a MSG tag, you can see Class, Instant, and Attribute values, and a message Path string (see pic). Manipulate these to access everything sequentially, updating the MSG members as needed.

Cycle through the parameter numbers, for each drive, doing only one at a time. I think you want to avoid multiple MSG enables, this could interfere with other system comms, and depending on how many drives you have, you could break your connection limit. I don't think it matters how long it takes to poll or write all the parameters, since this is an engineering function.

Hardest part will be manipulating the Path string member. In the picture the Path is $01,$01,$02,$t which evaluates to BackPlane ($1), Slot1 ($1), Front Port ($2), Dnet Node 9 ($t)...!! shortcut for ascii TAB, or Ctrl-T or hex 09.

That works for me, I configured th DNet module in slot 1, and sent the message to node 9 on devicenet.

ive just realised i didnt mention it was on ethernet, anyway the reason behind using several messages but only enabling them one at a time was more for being able to simplify the code for anyone else after me, for maniupulating the path which is .14, .15 for the forth octet is there a way i can move a value into 14 and 15 with one instruction as on the hmi i will have a multistate button and then use a DTOS to convert to string and move into the path, but as the last octet may go from 20, to 35 i need to be able to manipulate path.14 and path.15.

i will go with your advice and use one instruction and just manipulate the values. for reading or writing this many parameters would you cache the message and then disable after or just let it reconnect for each parameter read or write.

for reading or writing to the drive this will only be enabled when the line is stood and disabled when running, but from the HMI you can pull up the parameters from the database from the PLC

so far i have setup a UDT called VFD within the UDT i have 4 parameters named P031,P034,P038 just until i understand how it all works then redo with all the parameters.

if this is correct?

i have then created a tag called COMPARE using the data type VFD i just created this will be to read from the drive, what i want to know is how can i go about indexing through the parameters and moving the value needed to the Instance, i can move a value manually but do not know enough about the more complex instructions to index, the only way i could see would be a move instruction for each parameter and do it that way but that means loads of MOV and im sure there must be a better way to do it.

Rob

I would suggest a more efficient solution would be to default each drive back to factory, (this can be done by a single parameter P041 write), and then to write only the parameters that need changing from defaults.

I'm thinking that 90%+ of the 112 (?) parameters won't need writing.

You can compare each drive parameter UDT to a default set in the PLC, and only write parameters that need setting.

at the moment i am using a message for reading and one for writing but will look into consolidating this once i get a fully functioning program.
right i have used two SQO one branched around the other, the top one loads the parameter number into the instance and the bottom one moves the value for each parameter into the source element of the message, both SQO using the same control tag
once all the parameters have been wrote to the device would it be advantages to then read from the drive to compare against what has been sent or would the message not set the DN bit if the data had not been succesfully sent to the drive?

i have done this in V19 could i forward this to you to take a look over see if i have missed anything or maybe a scenario could occur where it could lock up, or if not maybe in PDF or a similar format

for the parameters etc i could not use a UDT in the SQO i just had to create an array of DINT's, also i am not able to use REAL's which may create problems when entering values into the HMI maybe i could just multiply out with an expression in the numerical input.

Rob

Rob, I had to do this for a customer last year. They wanted all of the drive parameters to be stored in the PLC, and the ability to upload and download when they wanted. I used one message for upload, and one for download. I used the drive checksum to "alert" of a change and the need to either upload or download.

Maybe you could expand on the checksum idea I am not familiar with what exactly this consists of

Rob

robw53 said:

at the moment i am using a message for reading and one for writing but will look into consolidating this once i get a fully functioning program.
right i have used two SQO one branched around the other, the top one loads the parameter number into the instance and the bottom one moves the value for each parameter into the source element of the message, both SQO using the same control tag
once all the parameters have been wrote to the device would it be advantages to then read from the drive to compare against what has been sent or would the message not set the DN bit if the data had not been succesfully sent to the drive?

i have done this in V19 could i forward this to you to take a look over see if i have missed anything or maybe a scenario could occur where it could lock up, or if not maybe in PDF or a similar format

for the parameters etc i could not use a UDT in the SQO i just had to create an array of DINT's, also i am not able to use REAL's which may create problems when entering values into the HMI maybe i could just multiply out with an expression in the numerical input.

Rob

Click to expand...

The .DN bit is meant to indicate successful completion of the message

You may add it to a pm if you do not want the whole world to see it

Rob-
To get the checksum from the PF40 drive, use a CIP Generic message, Get Attribute Single, Service Code of 1, Class of 1, Instance of 1, and Attribute of 9. The checksum should change whenever a parameter is changed. All I do is look at the checksum to see if the value ever changes. If it does, I throw a flag.

Hope this helps.
James

I don't appear to be able to add an attachment via PM, is this because I am a free member?