Convert a register binary value to ascii

I am using the Horner XLE units. I know in other PLC's this might already be implimented but not sure. So I thought I would put this out and see if anyone else has done this and if so what PLC they used and how they accomplished it.

What I would like to do is take a register which is 16bits and I would like to take that 16bits and send them to a scada system. However most of the ones I have looked at do not have the ability to send a binary value over. You send the integer then do the conversion at the scada side. However I am told this is not the best way because it uses significant processor time on the PC running the scada software.

So one solution that was presented was to take the value in the PLC and put the binary in ASCII format then just read the ascii string. So with that being said what would be the best approach to convert this number into an ascii string?

Ex: R100 contains a value of 15, which would be 0000000000001111 in binary. I would like to send the binary out to the scada software as an ascii string. So in the PLC I need to do the conversion. Any suggestions would be greatly appreciated.

I'm not even sure where to begin.

mrtweaver said:

What I would like to do is take a register which is 16bits and I would like to take that 16bits and send them to a scada system. However most of the ones I have looked at do not have the ability to send a binary value over. You send the integer then do the conversion at the scada side. However I am told this is not the best way because it uses significant processor time on the PC running the scada software.

So one solution that was presented was to take the value in the PLC and put the binary in ASCII format then just read the ascii string. So with that being said what would be the best approach to convert this number into an ascii string?

Ex: R100 contains a value of 15, which would be 0000000000001111 in binary. I would like to send the binary out to the scada software as an ascii string. So in the PLC I need to do the conversion. Any suggestions would be greatly appreciated.

Click to expand...

First off, everything in both your PLC and your PC is in binary. Every integer, every ascii character, and every floating point number is binary. Everything. No exceptions. The only thing that changes is how the binary data is interpreted. Whether your integer value of 15 is in the PLC, or in your PC, it is still 0000 0000 0000 1111. Period. End of story.

I'm not sure what scada packages you have looked at, but every single one that I am familiar with is capable of receiving a binary word.

When you see '15' on your computer screen you are not seeing the number 15. You are seeing the character '1' and the character '5' Your PC converts the number to the character for display on your monitor. So I have no idea where you got the idea that it was not the best way. Whoever told you that either lied or doesn't know what he is talking about. One way or the other, a processor is going to make the conversion. And the processor in your PC is the better choice because it already contains machine code libraries and display drivers to to the job for you, and it will do it much faster than a PLC can do it, not a little bit faster, a whole lot faster.

If you insist on doing the conversin in a PLC then you are going to perform a series of DIV/MOD looops and quite a bit of math to seperate the number into a series of up to 5 digits + a sign character, then you have to do some bit shifting to get the ascii code for the sign and each number character into a 8 bit byte, two characters per 16 bit word, and then transmit the string, which is now three times a long as the original 16 bit word - all of which involves your PLC processor and a programming language that was not optimized to handle ascii and strings.

Some PLCs have an integer to string conversion for use when you are using dumb devices to display certain information. If it doesn't have that but your processor has an integer to BCD converter and can handle 32 bit BCDs, then there is a cool trick you can do to skip programming all of the MOD/DIV steps (the processor will still have to do them, you only gain an instruction to encapsulate the operation), but its still the wrong way to do it when you have a SCADA system attahced.

Let the SCADA do what it is good at and let the PLC do what it is good at.

From all my education I do realize that computers, no matter if they are PC's or PLC's, work off of binary. This much I do know. Everything is 1 or 0.

What I did do was ask three different vendors of scada software which would be best. Either take an integer number over to the scada software and put it in binary format,just take over the binary string or take over each bit as its own tag. All 3 came back with about the same answer.

Here is what we will have, the scada software running on a PC, connection thru ethernet to 100 PLC's. The PLC's will most likely be the Horner XLE units.

They each claim that to take over each as its own tag is the best approach, my thought on this is they just want to make more money since all the software I have looked at is sold by the actual tag count. And the virtual tags are not included in this count. Any how I want to keep tag count down. SO to do that I need to find a way to take these bits and send them over as 1 instead of 16. Which is why I asked about sending them over as a ascii string or sending over the number and breaking it apart at the scada client/server. They all claim that because of the number of PLC's and the fact that so much information is being taken back to the server that the best approach would be send as ascii because to send it over and break it apart into its binary equivalent would take more processor time on the PC side and could cause missed information etc. If you would like I can post each of their emails using cut and paste to show you that they said this. My thoughts were that if you use a pc with enough HP that it would be able to keep up with all the calculations and such. I mean if oyu are using a 3ghz computer with 1 meg or better of ram this should work fine. So that is why I asked the question here. I figured here I would get a more honest opinion than from a sales person.

So if I understand correctly you would use the scada software to break the information back down to binary level. Is that what I am understanding?

Do you mind my asking what scada software are you using?
Are you doing anything similar to this?
How?

Thanks again and have a nice day.

Alaric said:

I'm not even sure where to begin.



First off, everything in both your PLC and your PC is in binary. Every integer, every ascii character, and every floating point number is binary. Everything. No exceptions. The only thing that changes is how the binary data is interpreted. Whether your integer value of 15 is in the PLC, or in your PC, it is still 0000 0000 0000 1111. Period. End of story.

I'm not sure what scada packages you have looked at, but every single one that I am familiar with is capable of receiving a binary word.

When you see '15' on your computer screen you are not seeing the number 15. You are seeing the character '1' and the character '5' Your PC converts the number to the character for display on your monitor. So I have no idea where you got the idea that it was not the best way. Whoever told you that either lied or doesn't know what he is talking about. One way or the other, a processor is going to make the conversion. And the processor in your PC is the better choice because it already contains machine code libraries and display drivers to to the job for you, and it will do it much faster than a PLC can do it, not a little bit faster, a whole lot faster.

If you insist on doing the conversin in a PLC then you are going to perform a series of DIV/MOD looops and quite a bit of math to seperate the number into a series of up to 5 digits + a sign character, then you have to do some bit shifting to get the ascii code for the sign and each number character into a 8 bit byte, two characters per 16 bit word, and then transmit the string, which is now three times a long as the original 16 bit word - all of which involves your PLC processor and a programming language that was not optimized to handle ascii and strings.

Some PLCs have an integer to string conversion for use when you are using dumb devices to display certain information. If it doesn't have that but your processor has an integer to BCD converter and can handle 32 bit BCDs, then there is a cool trick you can do to skip programming all of the MOD/DIV steps (the processor will still have to do them, you only gain an instruction to encapsulate the operation), but its still the wrong way to do it when you have a SCADA system attahced.

Let the SCADA do what it is good at and let the PLC do what it is good at.

Click to expand...

How many numbers are you reading from each PLC?

There are a total of 42 tags currently in use. 14 of these tags are pretty static, they are used mainly to set the units up for the days production. The other 28 are not so static and change as the day goes and gets reported back to data processing for the reports.

There will be 100 of these PLC's on the production floor when finished.

Alaric said:

How many numbers are you reading from each PLC?

Click to expand...

What SCADA software are you using? Won't it let you assign a tag address as a bit within a word like R100.00, R100.01, etc?

The person you've been talking to may not completely understand the SCADA system or he may be confusing some of the things he does know. In many serial protocols, the minimum quantity of data is one byte. When you ask to read a single bit, the protocol actually reads an entire byte and strips away the unused bits when it reports the value to the tag. That does indeed require a little bit of processing time, but hardly anything I'd call significant. When you want to write to a single bit it gets a little more interesting because you may need to read an entire byte first, then set or clear the bit within that byte, and finally write the entire byte back to the PLC. Maybe that's what your person is talking about.

I agree with alaric. Ascii does not seem like a good solution. I have done similar large scale systems using AB and Modicon PLCs over RF networks (and GE on smaller scales). In those cases, I preferred to pack all my data into consecutive registers. This included packing the bits into int registers. This allowed me to retrieve all the data with 1 message and send all my setpoints with one more. I've had to redo systems (done by others) where each site had 6-10 messages, and when I got done it was 2. I do not know where the salesmen are getting the idea its any easier on the SCADA system. True, I've done systems like I just described where the driver that was actually doing all the polling was being overloaded with all the messages, but the CPU itself was having no problems at all. So the moral of that paragraph is to start off with packing your data. Even if you have to keep the bits separate from ints, as long as they are together, the driver can grab them all at once.

An added bonus to packing the discrete info into integer files is that for most software packages, those 16 bits now count as 1 tag instead of 16. That particular trick will depend on whether the software you use counts all tags, or only IO tags. I'm pretty sure wonderware counts all tags, Lookout and intellution (I think) only count IO tags)

As for MMI packages, I've done similar things with Wonderware, Lookout, and Intellution. Wonderware is the only one I can remember giving me any trouble trying to address the bits of an int file. In that case, I was using modbus 4x registers, and I'm positive it was really the driver's fault, not wonderware's. Extracting the bits is usually just a matter of knowing the right syntax (N7:0/0, 40001.0, etc). I don't know anything about the PLC you are using, so i cannot even make an educated guess as to whether that would be an issue for you.


-jeff
PS, I have no problems with you posting those emails if ya want. It might help if we are misunderstanding something.

I am not sure what they are thinking. I gave them the information and this is what they came back with. They were all told that these bits are for read only, there is no write that goes on other than in the PLC itself. These bits are used to denote what is happening at the machine level as to what caused it to stop.

In the bulk mailing business there are only a couple of things that can cause a machine to stop.

1. One of the hoppers either did not pull material or pulled to much material. There are 8 hoppers per machine.

2. One of the jam detects detected a jam occured. There are three of these per machine.

3. The machine went out of time. One occurance per machine.

4. The operator choose to stop the machine. Two instances here either by the stop buttons or by lifting one of the guards.

These are all bit level. If the bit is on that is what caused the stoppage, if the bit if off then there was no problem. Data processing is not really going to use this information when they populate crystal reports. But should mgmt come back and say what happened as to why production was low they can query back and see all the faults as they occured.

Hope this clears things up. Like I said these will be read only by the scada software and I dont want to use up excessive tags, if I can take it over then translate it back to binary and it has little or no effect on the performance of the software package then that is the way to go.

I think they might also be thinking what is say 50% of the machine send back this register for decoding. Will the software be able to handle all 50 request to do the same job without screwing up? DOnt know.

Steve Bailey said:

What SCADA software are you using? Won't it let you assign a tag address as a bit within a word like R100.00, R100.01, etc?

The person you've been talking to may not completely understand the SCADA system or he may be confusing some of the things he does know. In many serial protocols, the minimum quantity of data is one byte. When you ask to read a single bit, the protocol actually reads an entire byte and strips away the unused bits when it reports the value to the tag. That does indeed require a little bit of processing time, but hardly anything I'd call significant. When you want to write to a single bit it gets a little more interesting because you may need to read an entire byte first, then set or clear the bit within that byte, and finally write the entire byte back to the PLC. Maybe that's what your person is talking about.

Click to expand...

No you are not misunderstanding what I am saying. As for packing things together, this is something that I have always done. I have a total of 3 areas in the plc which I am looking at. One is the bits, which is the issue I am working thru here on this forum, one is a series of DINT which are more or less static because all they are used for is to set the plc up for the daily production (14 of these) and 28 but I hope to lower this number, which are used for the production reports these are also consecutive. And if you look at the 14 and the 28 they are back to back so in essence they are consecutive as well. The only ones that are not are the binary. But if I put them in a register and sent them to the scada software that way then they would also be consecutive with the rest. So that in essense would make the scan time that much lower. Or wouldnt it have that much of an effect?

What would be really nice but I dont know if it is possible is the 14 tags for setup, finding a way to ignore them during production time unless they do change. Just some thoughts I am pondering over.

Hakutsuru said:

I agree with alaric. Ascii does not seem like a good solution. I have done similar large scale systems using AB and Modicon PLCs over RF networks (and GE on smaller scales). In those cases, I preferred to pack all my data into consecutive registers. This included packing the bits into int registers. This allowed me to retrieve all the data with 1 message and send all my setpoints with one more. I've had to redo systems (done by others) where each site had 6-10 messages, and when I got done it was 2. I do not know where the salesmen are getting the idea its any easier on the SCADA system. True, I've done systems like I just described where the driver that was actually doing all the polling was being overloaded with all the messages, but the CPU itself was having no problems at all. So the moral of that paragraph is to start off with packing your data. Even if you have to keep the bits separate from ints, as long as they are together, the driver can grab them all at once.

An added bonus to packing the discrete info into integer files is that for most software packages, those 16 bits now count as 1 tag instead of 16. That particular trick will depend on whether the software you use counts all tags, or only IO tags. I'm pretty sure wonderware counts all tags, Lookout and intellution (I think) only count IO tags)

As for MMI packages, I've done similar things with Wonderware, Lookout, and Intellution. Wonderware is the only one I can remember giving me any trouble trying to address the bits of an int file. In that case, I was using modbus 4x registers, and I'm positive it was really the driver's fault, not wonderware's. Extracting the bits is usually just a matter of knowing the right syntax (N7:0/0, 40001.0, etc). I don't know anything about the PLC you are using, so i cannot even make an educated guess as to whether that would be an issue for you.


-jeff
PS, I have no problems with you posting those emails if ya want. It might help if we are misunderstanding something.

Click to expand...

Thats only 4200 tags, I have SCADA systems with many more, I would send the bits as bits. While a 5000 tag license will be expensive, that large a database is not unusual.

mrtweaver said:

The only ones that are not are the binary. But if I put them in a register and sent them to the scada software that way then they would also be consecutive with the rest. So that in essense would make the scan time that much lower. Or wouldnt it have that much of an effect?

What would be really nice but I dont know if it is possible is the 14 tags for setup, finding a way to ignore them during production time unless they do change. Just some thoughts I am pondering over.

Click to expand...

It could cut the scan time in half. In my case, since I wa susing radios, the vast majority of the scan time was spent in overhead type activities, the time it actually took to send an extra word or 2 of data in any given scan was negligible. Even if you are using hardwires comms, thats going to be true, just not as blantant. So, in *theory* you'd cut the scan time in half.

As for ignoring the 14 setup registers. Not too difficult, really. It would need to be a 'feature' of your driver. Look for a report by exception option. Then, just make sure those 14 regs are either at the beginning or end of your range and they will be skipped automatically.

I really can't fathom where the salesmen were coming from. Like someone already kinda said, they're salesmen, they could very well only have a dangerous, partial knowledge of thier product.

aand I just read the part where you told us we are helping out a bulk mailing machine .... must ... resist .... urges .... to .... scr


-jeff

Dont worry about the bulk mail house scene, while it is true I work for one you need not worry about the mail we send out. We dont do those trash bin types of mail that everyone just circular files when it comes. The bulk of our work is for companies such as AAA, AARP, and some other big names as such. But ones that most people get where you get smelly stuff, or credit cards, or someother advertising junk we dont do. So no need to scream unless you dont like AAA or AARP or things such as that. However I have heard thru the grapevine, dont know where it is right now exactly but a bill is being worked on in our government where if it does pass it will be similar to the DO NOT CALL list for phones, but it will be a DO NOT MAIL list for junk mail. This way people can get taken off these list. But like I said I dont know the exact status of it, I just know it is out there.

Hakutsuru said:

It could cut the scan time in half. In my case, since I wa susing radios, the vast majority of the scan time was spent in overhead type activities, the time it actually took to send an extra word or 2 of data in any given scan was negligible. Even if you are using hardwires comms, thats going to be true, just not as blantant. So, in *theory* you'd cut the scan time in half.

As for ignoring the 14 setup registers. Not too difficult, really. It would need to be a 'feature' of your driver. Look for a report by exception option. Then, just make sure those 14 regs are either at the beginning or end of your range and they will be skipped automatically.

I really can't fathom where the salesmen were coming from. Like someone already kinda said, they're salesmen, they could very well only have a dangerous, partial knowledge of thier product.

aand I just read the part where you told us we are helping out a bulk mailing machine .... must ... resist .... urges .... to .... scr


-jeff

Click to expand...

Hy guys;

One suggestion that could apply here:
http://www.heapg.com/OcsManuals/OPC%20-%20Horner%20KEPServerEX/MAN0802-02.pdf

This offering is for Kepware OPC server using the CAN interface board of the Horner units. Any SCADA with a OPC client channel could read the registers of the XLe through that, without conversions.
Hope this helps,
Daniel Chartier

No I have that file. This meerly tells you how to connect to the Horner device using an OPC server such as KepWare. But if you goto KepWare they tell you what all data formats they support. And it is similar across the board, DINT, INT, Boolean, ASCII, etc. but not a word of boolean, if you want the word then you must take it from the INT format and convert it. Now where you do that conversion is up for debate. Which is one of the reasons I started this thread.

dchartier said:

Hy guys;

One suggestion that could apply here:
http://www.heapg.com/OcsManuals/OPC%20-%20Horner%20KEPServerEX/MAN0802-02.pdf

This offering is for Kepware OPC server using the CAN interface board of the Horner units. Any SCADA with a OPC client channel could read the registers of the XLe through that, without conversions.
Hope this helps,
Daniel Chartier

Click to expand...

Will the Horner unit allow you to mask out the bits within an integer? I have done this ins RSView to get an extra 128 bits when I was nearly out of tags on my licen$e.


I am sure the syntax would be different for your unit...

I would also concur with the others that converting to ascii should be unnecessary...