Durant Totalizer to TI545

I have another problem that I can not find the information/answer for. I looked in the manuals and at the Siemens site, and done every Google I could think to write. But alas, no guidance.

We have over 80 Durant Totalizers, model #57601-401, that we use to count parts made. We run at least three of these per line for redundancy. Due to some recent events management now wants to know if they can get this information without it having to be taken down by hand at the end of every shift/day. Stupid me says I think that should be possible, one of the reasons my mouth out ran my brain was I thought this is the perfect vehicle to get them to fork over the funding for a SCADA package. I have been learning how to transfer data through the 2572A card thanks to guidance from this site.

The Durant Totalizers use the ASCII code with the RS485 specification, this got my attention as I send messages to a marquee in ASCII. According to the Durant manual the Totalizers can be addressed 0-99 for polling reasons and the Totalizer will respond with what information you are requesting. All sounded just great and fairly easy to do until I tried to find out how to send/recieve messages from port 2 on the 545-1101/2/4/5. I figured this would be the correct port since it can be configured for RS485 by dipswitch #1 set to the right according to the manual (I really have been reading the manual before I had to ask you guys. I always feel like an idiot when you guys have the answers so seemingly easy).

So I ask, is there a way to program two-way communication through port 2?
Next, from the information I have given, is there a better way to do this? I have an un-used BASIC Module (505-7101) and read a little on these and wondered if this would be a better option. If there is different card that I could/should use, please mention it, there might be one laying around this place.

Thanks for taking the time to read this and thanks for any replies!

I haven't done this directly with the 545, but I have done simple ASCII using the BASIC module you speak of. In my case I had it talking to a serial port on a Reliance Electric AutoMax DCS.

I would much rather have done this job using the Profibus scanner card that SST makes; however, it seemed outrageous to pay $10K for this one card for this simple task. This price was quoted both by the local AB and Reliance people; the feedback that I got was that it was a product SST indicated that they were phasing out and wanted distributors to purchase quantity 10 at a time, either that or pony up big bucks. When I first saw this scanner card about 10 years ago it was about 1/3 of that cost.

The BASIC module program was pretty straightforward, the biggest issue that I found with it was that I couldn't pass signed integers (only unsigned). For what it's worth, CTI makes a couple of different communications modules that would probably be the easiest way to do this job.


Tom

Thanks Tom,

I had contacted CTI yesterday along with the TI reps, and some other people I know of, and this particular application seems to have alot of people scratching their heads.

They all agreed that this "should" work and I have read the manual a couple of times now but I still have not gotten anywhere with it.

Is the B-TERM Basic Module Terminal Program, I have disk 1 of 1, the correct program to use to interface and program the Basic module, or do I need something else like the VPU? When I log onto the Basic module I get some errors sometimes and other times I get strange characters for the letters I type.

Thanks, to all.

First, you definitely can't get 2-way comms out of the CPU port. You can set it to be a printer/terminal output port where you use the SFPGM instruction PRINT to control the output but in that mode it's unidirectional. You can also set it for normal operation where it is bidirectional, but here you have no control over the transaction from within the CPU - it's all done from the PC, HMI, programming software, whatever, attached to the CPU. If these totalisers just spew out an ASCII sequence of digits the CPU won't know what they're talking about. You would need to have this data wrapped in a 505-series task code with an instruction saying what to do with it (e.g. write), where to (e.g. a V-memory address), a checksum and message length counter etc. I doubt if you could set them up to do that.

So the BASIC module is the correct option to consider. BTERM is just a terminal emulator program which has a few pre-programmed keystrokes for LOAD, SAVE, etc. It's not particularly smart and it is DOS-based so immediately you have to consider interactions within Windows. If you're running XP, have you tried setting the compatibility options for this application? The other thing to check is have you got the last version from the Siemens web-site http://www.sea.siemens.com/automat/product/plc/505/au505dl.html#505_utility? Odd characters being displayed in the old days used to be a symptom of not having the standard ANSI display drivers loaded, but I don't think that's been a problem for many, many years.

You shouldn't necessarily have to use BTERM. You should be able to use something Windows-compatible like HyperTerm to LOAD and SAVE the contents of the module to a text file on your disk. Edit it there with a standard text-editor, taking care not to use a word processor like Word which could embed its own formatting characters in the file. Digging in my memory I think the standard settings for virtually all TI comms devices was 7 data bits, 1 stop bit and odd parity. I can't remember if the BASIC module allowed you to control this from dipswitches or not. The BASIC module has RS232 ports only, so you will require some electrical conversion to RS485 in this set-up as well.

I do remember the BASIC module being used in the past for things like weigh scales and barcode readers so in principle this should be capable of working for these totalisers. However the devil is in the details!

Regards

Ken

Why?

management now wants to know if they can get this information without it having to be taken down by hand at the end of every shift/day.

Click to expand...

Just curious, what will capturing all this data into the plc do for you? You've already mentioned that you WANT to purchase a SCADA. So, assume you somehow get all you data into a PLC, what are you going to do with the data? Print a report? Save as many data points as PLC memory allows? How will management get this data?
I'm just wondering if your concentrating on the capture piece, and not looking at the overall requirement.

Ken

Thanks Ken M.

You are definetly right on about the barcode readers as that is the main desciptions I have seen and from the individuals I have talked to.

I have one laptop with Windows XP and one with '95 and this is the one that I mainly use for programming the TIs. I will try to use this for programming the Basic module first.

I have a RS232 to 485 convertot and the cables are made up correctly, I beleive, but you cleared up what was happening for me. Thanks again. That B-TERM program is Rel.2.5 dated 2-6-95 so it may well be antiquated.

I will delve into this much harder now that you guys have confirmed that this is probably my best chance for success.

Thanks for letting me know I am not chasing my tale. Now, bring on the grey hairs, this should be fun!

Ah... Mr. Moore, thanks for the reply.

I know you have helped me many times before, and I think you also know I am just learning this great trade, so bear with me if I am doing this wrong.

This is what I see getting done:
I do not see any other way to get the data from the Totalizers without bringing into a PLC. So I would bring each count into a memory location and keep that updating. From there I could calculate the speed for the production run. Also I could track "no flow" time, which is not really down time, but is a very important result of our environment. They currently write down these numbers and that results in transposition errors so I could help eleviate that. Also the customer who is at the direct end of this supply is starting to charge us for loses that we can not prove are our responsibility. Maybe that part does not make sense, but it is a large factor in our facility. We are directly connected to the customer. Also this number could directly feed back into line control and help maintain a constant, even supply to the customer. That was a big project I had worked on last summer and was able to reduce damage/no supply/over-pack to an acceptable level. These numbers would also go into their daily/shift production reports. This is only one location where we use these Totalizers to track production, there are a lot more, and they seem to be very accurate so I figured pulling there total off would be the best way to get accurate counts to a SCADA package.

If this is all the wrong way of doing a project such as this, I must have a wrong understanding of the SCADA product. I do know Supervisory Control and Data Aquisition is much more capable than just setting there collecting numbers and dust, but I need to start off somewhere. And with the number of product that is delivered to the customer every minute, this seemed like the perfect place to start.

Just a few additional thoughts...

If you're running WinXP try using VirtualPC. You could install the regular old DOS environment and run Bterm from within that if you wanted to. I presently run TiSoft from within a VirtualPC Win98 environment and it's much more stable than Win98 ever was by itself; no communciations problems.

The BASIC module application that I've got is somewhat like what you're talking about. We already had a Maple Systems OIT hanging off of the TI545 and they wanted to be able to view process feedback from the AutoMax. So we have a unidirectional communication happening where the AutoMax Basic Task spews data out the 25pin serial port on the front of the processor. We then buffer this in the TI505 BASIC module and based on a derived format of starting character, data length, and ending character, we then write the data into V-memory. Determining the starting and ending characters was simply a matter of figuring out what the two systems had in common or needed to see for this ASCII string coming from the AutoMax.

Purely from the process troubleshooting viewpoint, most of this data from the AutoMax I stuff into a few different shift register tables; which one depends on whether I want to see the information as event driven (fault, etc.) or as interval driven (log every xx:xx secs/min, etc.). This machine is only recently being targeted for an HMI application, but we've had the OIT and the AutoMax hanging off the TI545 for a long time now.

One other thing to consider that may help you in your SCADA quest is if you start pulling in this data with something like the BASIC module, you could then direct it to a serial printer from the TI545 port. Once you start printing out the data that they're interested in, it may be the perfect catalyst for bringin in a HMI package. Think about it... if they want the data, and you provide it... but they have to type it into a spreadsheet, document or whatever... it wouldn't normally take too many occurences of this before they see the benefit of being able to query a database for this information. Now this doesn't mean that they're going to give you an open checking account for SCADA, but if you plan it out well you can use each opportunity like this to be a stepping stone to get what you really would like to see out of the entire system as a package. Of course, if they really use the data and see how much paper it takes to print this stuff out, this may be another element in your favor.


Tom
PS - With the way that things have changed with the job in the last several months it's hard to find time to get up here to check things out...but this is way cool stuff.

Tom,

You hit everything right on the head of the ultimate end result I would like to achieve. But since I am new there is always that concern about whether your doing it correctly. After reading your post I am grateful there is this forum to help and re-assure those of us whom are less learned than you guys.

I was really getting concerned when all the people I talked to had not done anything like this.

You guys rock and anymore suggestions or guidance is more appreciated than I can ever convey.

TIs and this site rule!

Okay, I have a test system set up and I have programmed the BASIC module to output the, I believe, correct code to access the Durant Totalizer.

When I enter RUN the BTERM display shows that I am outputting the correct code.

But for the last two days I have not been able to tell where or if the signal is coming back? I have used INPUT, CALLs OREADs/IOWRITEs, PCREADs, PCWRITEs (I did not think the PCREAD/WRITE would work but I did try) and still I have not seen a change in the chart table.

I used the PRINT statement for the output message to send the code 62 48 56 82 67 68 48 40 419 13 and again all looks good when I go into Run because I get the proper ASCII of 3E30385243443028A30D.

So how do I access the input message, if there is one, and with which instruction/statement?

Tom, which words do you see change?

When I'm back in the office Monday I'll look at what I used for this, but from what I remember the application was set up so that it echoed the contents of the communication to the BTerm display; the other place that the information would go to is to V-memory via the PCWrite instruction. I believe in order to see all of this at commissioning without having two computers I had a test screen on the OIT that displayed the V-memory contents.

Several years after I had done the original application I needed to modify it to pass more points of data, from four originally to 8 or 16; and I had a problem with the BASIC module locking up with the new program. Tried everything that I could think of but still had the same problem, and the Siemens hotline wasn't too much help either. I was finally able to get put through (at Siemens) to an acquintance there whom previously was their lead man for the 505 support; after the S7 was out for a while they had transferred him over to S7 land. After a few go arounds he was able to help pinpoint the problem in my application. If you get hung up too terribly bad on this I can pass his name along to you. Everybody knows what it's like sometimes starting something new, it's usually something small that we end up tripping over; that's what the case was in my modified program.


Tom

One other commissioning thought, as you start this up it is going ot be easier to figure out things if you happen to have this TI505 hardware and a single totalizer sitting on the bench trying to get the communication happening. Once you've been able to successfully communicate a single point of data from a single station, then you can move on to multiple connections.

Which brings me to another question, how are you physically planning to talk to all of these totalizers? Maybe you already stated and I missed it; but is this over RS485 or something? It may, again, be simpler to get a point to point interaction working and then throw in the single master to multiple slaves code. It's all part of that being able to walk before you can run thing. The smaller, easier to handle 'chunks' that you can break things down into - the easier it is to work through any problems.


Tom

ilikbeer, (metoo)
hi hows things?, what you are trying to do is very difficult without a SCADA system to display the data, from my experience with basic modules is they tend to get terminal lock on a regular basis. How do you intend to talk to 80 unit? do the totalizer support an RS 485 port with multi drop nodal addressing?. Would it be easier to dedicate a PC rather than the PLC to receive this data? you could write a small VB application to poll each unit and display an accumulate data, as for the the RS 232 serial, the only other way is to use a multi port serial adapter, but I have only ever seen these with 9 ports.

best of luck
Lance

Tom, thanks again for the help.

Yes, i am starting out with baby-steps here as I do not want to have several issues causing problems and not being able to eliminate them.

I have setting on my test bench:
TI555-1105 ROCK SOLID PLC in an 8-slot rack
2 laptops. One running Ti-Soft + PLCs.net and the other one running B-TERM.
1 Durant Totalizer with RS485 comms
A RS232/485 convertor
and I hope all of the properly made comm cables.
I am fortunate to work for a company that gives us access to this equipment.

The Totalizers allow themselves to be individually addressed and they ignore any message not addressed to them. So once I get comms working on one of them, it "should" be just changing the polling address to access their counts.

I figured it would take a PCWrite to put the count into V memory it is just that I can not figure out where it comes in at? I mean it physically comes in on port #2 but does the count come in on WX1,2,3,4, or WY5,6,7,8, or something to do with the INPUT statement. I am just not getting this part. The grey hairs are taking over.

I have read the manual so many times I believe I am skipping over that light-bulb step that says "Hey stupid, use this instruction".

All said and done though, this stuff is a ball.
Best thing is, they pay me to do a job I truely love.

One more question that relates to Ken Moore's post:

Just curious, what will capturing all this data into the plc do for you? You've already mentioned that you WANT to purchase a SCADA. So, assume you somehow get all you data into a PLC, what are you going to do with the data? Print a report? Save as many data points as PLC memory allows? How will management get this data?
I'm just wondering if your concentrating on the capture piece, and not looking at the overall requirement.

Ken

Click to expand...

From the little information I described earlier that you hit on the head about my goals, am I going about this properly?
I mean, is there a better way to achieve this data collection and distribution? Ever since Ken posted that, I have this feeling I am going about this the wrong way. I thought about PMing him but I beleive all discussions about a post should stay on the post so others like myself can learn without missing things that may have been discussed else where. If I can get this part done I think they are willing to buy ControlShop from FasTrak in a heart-beat so that is my incentive right now.

lancer,

Thanks. You posted while I was answering Tom. I hope this post answers some of those questions but about the VB, i do not know. I had just started doing some VB exercises 2 weeks ago when this all came about and my PC skills are even more limited than my PLC skills.

I've used a CTI2573 to talk RS485 ASCII protocol to a string of remote totalisers (Brand: Contrec), there was a bit of work getting the format tables set up, but this arrangement has performed flawlessly for several years now.
regards
Phil