I have attached a screen shot of a db table I made…I need to check two columns in the table, Card Number and Pin number against 2 tags in my PLC. The PLC will have a Card Number & Pin Number stored to in to data registers that I will bring into Ignition and if those 2 PLC tags match Card Number & Pin Number in a row of the table I need it to write a value back to my PLC. Later on I will also need to make another database that stores the whole row of data that the Card Number and Pin Number matched with after it wrote back to the PLC…Like the Company, First Name, Last name…any help would be appreciated on best route for this.
you could use a transaction group with a where clause or scripting, which ever is easier for you to use. I would do the logic in scripting and then use the transaction group to store it in the db.
Maybe I should explain what this will be doing to begin with I guess. Basically this will be used at a Waste Water Disposal in the Oil and Gas Industry. Our customer will enter all their customers, drivers names and card and pin number that belongs to each driver. Then I have PLC’s programmed a long with an HMI on site. They scan the card and the number is stored to the PLC, then they input their pin number on the HMI which is also stored to the PLC if it matches the Card and Pin Number in a row of the table database our customer created it will allow them to dispose by writing back to the PLC that Card and Pin are valid. After that I need to store all the information for the person the card and pin belonged to for reporting. I am just kinda of messing around with how I think it should work right now. I have the plc’s, card readers, and hmi’s working just threw together a quick project on development server to start bouncing around some ideas of best way to make ignition do its part.
The entire thing can be done with a single transaction group. In fact, that would be my personal preference. 
Here’s how I’d do it:
[attachment=0]2014-02-12_6-49-55.png[/attachment]
[ol][li]2 PLC Tags:
One is a string containing Card Number and PIN (i.e.: “12345,10001”). This eliminates any slow update of values that may give an incorrect response.
The other an integer to provide a match status (1=Match, 2=No Match)
[/li]
[li] A Run-Always Expression to find a comma in the CARD/PIN string. This becomes the trigger for the rest:
indexOf({[.]Test/CardAndPin},",")In the Triggered section:
[/li]
[li] Expression to extract the Card Number:
substring({[.]Test/CardAndPin},0,{[.]FindComma})[li] Expression to extract the PIN:
substring({[.]Test/CardAndPin},{[.]FindComma}+1)[li] SQL query to check for a match:
select case
WHEN count(*)=1 THEN 1
ELSE 2
END
from custTable
where CardNum='{[.]Card Number}' and PIN='{[.]PIN}'[/li]
[li] Reset CARD/PIN string:
''[li] Write to the history table:
INSERT CustHistory (Customer, FirstName, LastName, CardNum, PIN, t_stamp)
SELECT Customer, FirstName, LastName, CardNum, PIN, now()
FROM CustTable
WHERE CardNum='{[.]Card Number}' AND PIN='{[.]PIN}'[/li][/ol]
Note that if you want to log invalid attempts by a customer, you can remove the PIN section from the WHERE clause. If you want all login attempts, remove the where clause. In these instances, I’d also add the match status to the history to tell the difference.
EDIT: Edited for grammar and spelling… and punctuation… and neatness 
To continue, the trigger setup:
[ol]
[li]Check Only evaluate when values have changed
Click Select Tags and use only the one for finding the comma.
[/li]
[li]Use the comma finder as the trigger
[/li]
[li]Set the be active>0 / non-active<=1. The is>0-only condition will trigger on a -1. Weird but true.[/li][/ol]
Jordan -
Thank you very much for your very detailed explanation of how you would go about doing this. Everything made great since except for one thing I did not understand that was probably the first and most simple. You suggested just using one tag as a string with the Card Number & Pin Number. Well the Card number will be stored in a data register in the PLC and the HMI will store the Pin number in another data register within the PLC. Not really sure how to combine two separate words into a string, I have never did that in the PLC’s we use???
Ok. What PLC’s are you using?
IDEC FC5A-D12S1E Its the Microsmart Ethernet PLC programmed with WindLDR in the Automation Organizer suite.
Never used them. Are you connecting via Modbus?
Yea it will be modbus. I mean we use Allen Bradley and GE and Scadapack as well, but the Idec Microsmarts will be great for this application. We only use the other Plc’s for larger projects.
OK let me find some documentation and dig in…
Only thing I have ever seen is maybe the RXD command, but that will still store the Card Number and the Pin Number to multiple data registers…
Wow. I thought Omron was bad at stings. IDEC takes the prize… 
There would have to be a bunch of data moving around, shifted, disassembled, smacked with a hammer, and re-assembled to make a usable string over MODBUS!
I’d write a very eloquent rant about PLC manufacturers and string manipulation, but I’m trying to be good. 
You may be able to get away with two integers and a trigger. It’s just that if there’s a hiccup in how the data is set or reset, then robust kind of goes out the window.
Sorry, I should explain a bit further. Most PLCs will put 2 bytes of ASCII in each data register. IDEC will put 1 byte in each data register.
So, in ASCII terms, you would never get a strings, because the fist thing it will see is a null character...
Out of curiosity which PLC do you use that allows 2 sources to write two separate string values to one one spot and combine them into one larger string???
Im almost positive Idec writes two ascii characters to one data register…
[attachment=0]Ascii break down.JPG[/attachment]
There should not be any conversion going on to keep it in ASCII. In ASCII, ‘1’=31h, ‘2’=32h, etc. To keep it ASCII in memory you should see it as 3132h, not 12h.
According to what I’m seeing, it appears that if you store the incoming stream to D10000-D49999, no conversion occurs.
Ok maybe I made a little progress before my card reader was reading the value of the card perfectly in the data register when i was using BCD to store it. Well I just played around with ASCII no conversion and and when i monitor the values the Scanned card bring in in DEC (W) values I get numbers but not the card number which i attached a picture of. When I change batch monitor to see what values look like in ASCII (W) values I get the card number which I also attached a picture of. Is this becoming more of a working deal? Or still not what I need to accomplish?
[attachment=0]DEC (W) Values.PNG[/attachment]
[attachment=1]ASCII (W) Values.PNG[/attachment]
That looks a lot better! Good work!
BTW, if you can monitor in hex you can see the individual ASCII codes 
As I see things the next part should be to read that ASCII string into Ignition. Once that is accomplished, two of the big hurdles are taken care of!
Also, how is the pin being entered? That’ll give me something to mull over. 
It allows me to monitor any pretty much anything…so I can monitor in HEX(W) HEX(D) and pretty much all other formats…The HMI will be IDEC as well colored Multimedia touchscreens, and I just tell it where to store the PIN Number value in the PLC…IDEC actually allows you to pick if you want to store 1 or 2 bytes of ASCII per data register with the RXD command…so Ill test when I get back at the office tomorrow. Have not had the need to bring a string into Ignition thus far, so would it just be as a holding register? Also I noticed it lets you bring in BCD and found out their was a BTOA conversion which converts BCD to ASCII built in as well in IDEC…