Best way to..

[Buckaroo 0]

I have an existing Allen Bradley 5/04 connected to a Panelview 1000. The system is a monitor of a group of vessels. The product in the vessel in user inputted via the Panelview 1000 and is addressed in the PLC as N13:xx. What I would like to do is determine what product is in the vessel and set a parameter in the PLC based on it. So for example if I have SHERBET in a vessel, I can go to N13 and see this data: radix is ASCII N13:10 = SH N13:11 = ER N13:12 = BE N13:13 = T<space> N13:14 = <space,space> radix is DECIMAL N13:10 = 21320 N13:11 = 17746 N13:12 = 16965 N13:13 = 21536 N13:14 = 8224 What would be the best way to evaluate the product name? Using the ASCII, Decimal, or maybe even the Binary data of the product name? My first thought was to add the Decimal values together and then compare that to known values to determine what is in the vessel. Example: If vessel 1 product is SHERBET then temp value is A otherwise temp value is B Anyone have any thoughts or ideas as to the best way to do this? Thanks for any ideas Tom

[Kiwi Sparky 0]

Is the Panelview input going directly to N13 or is Panelview tag actually a ST (string) type that is being moved to N13 in your PLC program If it is ST type, use the ASR instruction to compare to a known value and add logic required after that asr.bmp

[JeffKiper 9]

have the PV write to a string and compare them. Is how I would do it. Or are there only so many possible names? If there are say 5 different possibilities use a milti state indicator and have 1 = product abc, 2=def, 3=ghi, etc.

[Buckaroo 0]

First off thanks for the replies. The product names are addressed as N13:xx in the Panelview with the data type as character array. There is aproximately 15 different product names for 7 vessels. Currently there is no string file (ST) in the PLC program and as far as I can see the product name addresses are not being used elsewhere in the program. I will create the ST file and experiment with that. Thanks again Tom

[paulengr 44]

Having done some similar things before, the last time I did it, I did it two ways depending on the implementation. In one case, I was using a full blown server/client based SCADA system. The PLC stored product codes. The SCADA held an index table with names to product codes. There was a page where you edit the available names in the system (which corresponded to product codes). The screen would show a table of 10 names and allow users to change them to anything desired. This was a product code table, but they didn't realize that the numbers "1,2,3,4,5,6,7,8,9,10" down the left hand side were more than just arbitrary integers from the PLC's point of view (actually, the PLC never even saw the names). The important part here is that the product codes were also being sent over to a database where we could production tracking and reporting, so having consistent, standardized names for everything was important. The end users on the SCADA never saw the product code backend though. On the silo display screen, clicking on the silo or a batch recipe brought up a product name menu where you selected the contents. Then the silo displayed a name, but the indexing was done in the SCADA...again, end users never noticed the guy behind the curtain. In the same plant on a Panelview 1000 standard system, things were a lot more limited. We had a recipe system with names that went like XX-YY-ZZZ. The XX was ASCII but the rest were digits. Recipes changed rarely but in this case I didn't have the SCADA backing it. Instead, the users had "F5 UP", "F6 DOWN" type buttons located on the screens where you enter "product names". Hitting the buttons cycled through the allowable product code combinations. This did away with the "submenu" and since each of the components of the product code (XX, YY, ZZZ) were very short, again, the users were insulated from the magic going on in the background. Now, management actually liked this system for a very important reason. What if your users fat-fingered "SHERBET" and entered "SHERBERT"? In fact, that wouldn't even be a fat-finger error since that's the way some folks spell it. Now your system breaks down. BUT, if you present them always with selection menus it mistake-proofs the system from simple spelling errors and it also reduces the number of keystrokes necessary to set the product names. In the case I had with the XX-YYY-ZZZ names, originally the users were entering everything manually. We were constantly fixing mistakes especially the fat finger ones (10 vs. 100). Once I put in the "menu" system and made it impossible to enter "illegal" entries, once in a while there was a mistake where someone would make a run of product A when it was supposed to be product B. The only way you can fix this is if you have some way to cross-check it or you have two different humans cross-check each other (error rate goes from about 10% to 1%). So...it might not answer your question since my answer is that I simply bypassed doing any kind of comparison operations on strings, but it answers how I handled it. If you really want to do string comparisons, I haven't worked with a SLC 5/04. On some PLC's there is an ASCII string comparison command (if you use ST files), and I think you can move data back and forth between ST and N with string copy commands. On others, you've got the file commands so you can use FSC (file search and compare). If you didn't have those but you have FOR/NXT, you could do it with a loop (FSC and string compare are just purpose-built loops anyways). Otherwise, you are limited to unrolling the loop and using a whole bunch of EQU/NEQ instructions. Not clean but you work with what you have.

[Buckaroo 0]

Paul, thanks for the reply. I believe that the system they are using here has the product names in stored in the Panelview and they are selected by the operator. I will have to confrim this for sure but if so then that eliminates the possibility of spelling errors. I may end up using the compare instruction for my requirements. With the 15 or so product names I am really only concerned with 2 of them. For example if product is A then temperature is X if product is B then temperature is Y for all other products temperature is Z. So possible this is the route I will try. However I have been moved to another direction for a few days so I will have to revist this at a later date. Again thanks for the replies. Tom