Motorola MOSCAD/Toolbox, radio links? 1

[NoHoCa]

We inherited a SCADA system which uses Motorola MOSCAD ("-L" I think) hardware for RTU/store & forward operations. It uses "Toolbox" software for configuration and logic programing. Toolbox version 8.50, which runs on Windows 2000, supports up to 41 zones on a radio link. For example, radio links 1/1 through 1/41.

Toolbox version 9.50, which we use on our WinXP laptop for configuration, only supports 9 zones on a radio link. For example, 1/1 through 1/9. It poses a problem when the field system operates on many zones but the software only supports the first 9 zones.

Can someone explain to me why Motorola appears to have migrated their product by reducing the capabilities of the radio network?

 

[SCADABOY]

You have the same capability with the 9.5 and 9.54 toolbox software packages. Use your MDLC configurator to vary your link settings to match what you are presently using. If you don't and start using the higher versions of toolbox, your links will be incorrectly displayed when you go to monitor them or you will enter incorrect links when you go to change links.

In the MDLC configurator of 9.5 or 9.54 (you have one in the Toolbox 8 version to compare to), modify the number of links per radio group and they become available for use in other groups. For example: we use radio group 1 - 30 within radio group 1. Our groups 8 and 9 are set to zero. The links they used became free to use in the lower groups. Be sure to save your changes with a new name and activate them. Once that is done, it is clear sailing.

Hope this is of some help.

Charlie

 

[SCADABOY]

You have the same capability with the 9.5 and 9.54 toolbox software packages. Use your MDLC configurator to vary your link settings to match what you are presently using. If you don't and start using the higher versions of toolbox, your links will be incorrectly displayed when you go to monitor them or you will enter incorrect links when you go to change links.

In the MDLC configurator of 9.5 or 9.54 (you have one in the Toolbox 8 version to compare to), modify the number of links per radio group and they become available for use in other groups. For example: we use radio group 1 - 30 within radio group 1. Our groups 8 and 9 are set to zero. The links they used became free to use in the lower groups. Be sure to save your changes with a new name and activate them. Once that is done, it is clear sailing.

Hope this is of some help.

Charlie

PS If you upgrade again from version 9, go to 9.54 and bypass 9.52. It has problems.

 

[NoHoCa]

Thanks Charlie. Since you seem to know MOSCAD, I wonder if you'd entertain one more topic. Working with a generic Maple OIT, via RS232/Modbus, there is a formula to translate MOSCAD tags into Modbus addresses:

Modbus = (Table * 2048) + (Column * 256) + Row + 1

I realize that this formula is for relative addressing, and that for absolute we'd probably need to add 300,000.

I noticed on the Maple product, they only support Moscad tables 0 through 4. I also noticed that if I attempt to apply this formula to a higher table, for example Table 35, that the formula no longer yields a Modbus address equal to some of those which are already in use.

Do you have any advice on whether or not these observations are accurate, and if so, comment on the limitations of the Moscad-to-Modbus conversion?

Thanks very much for any tips...

 

[SCADABOY]

Unfortunately, I am not familiar with Maple software. However, I have to make a few basic assumptions. Fully aware of assume=ass out of u and me.

Our system uses Intellution software (which should be similar) along with the Modbus interface to process our alarms and data. Our analyst asks us for a table, row, colums addressing to find the data. I have to assume that your MOSCAD RTU and FEP programs are adaptations of the MOTOROLA G-RTU and G-FIU programs developed by Mark Brauer. Referring to table, Row, column is referring to table (annotated by Application Programmer) that the data from RTU is received in, The column is the column correlating to the designator the data sent from the RTU (i.e.-STAT, DO, CONFIG), and the row is the site from which the data is received. It can/should be the same row as the RTU in the sites table of the application. I do not know the offsets required for your software.

I might suggest that you ask for a training course taught in Chicago near the MOTOROLA complex. Mark Brauer used to work for Motorola but now has his own consulting firm in Chicago. His company is ITS in the suburbs of Chicago. If your company has an account, you have free tech support.

My apologies for begging off to a contractor.


Charlie

 

[NoHoCa]

Thanks again Charlie. My question is probably more related to the configuration of the (relatively dumb) Maple 6" operator display. Maple tech support doesn't know a thing about how their displays are used, so I'll go find an online forum for that product.

Clarification on the addressing - The Motorola product uses single and multiple column tables to address its data. The tables are fully configurable. So in your example above, one table may have rows which are addressed by the RTU site number, but many tables are generic for "holding" data and the rows have nothing to do with the site number. Similarly, the column name (you mentioned "STAT, DO, CONFIG") is user selectable and could be named anything.

I don't want to come off as a wise guy, and I'm just learning the nuances of this platform. But it's worth pointing out how generic/customizable it is. I cannot assume any of my tables are configured like any of yours, unless we both developed off the same baseline...

 

[SCADABOY]

NoHOCa,

You are correct. I the previous posting, I mentioned assumptions. One was that because it was a SCADA system, that the programming had some basic generic properties. Secondly, you are right about the table addressing. The data from the RTU's will correlate to a table, row, and column of an FEP (FIU). The "Stat, DO, Config" reference is used in our system. The system can appear daunting at first. With patience and time, it is possible to figure it out. You mention nuances and there are many. If you have the toolbox software, you most likely have the tech manuals. They address everything you have except your specific program. If previous people who did the programming left a trail, it will be in the description of the tables and the process logic. Maple probably works similarly to Intellution (we use) and is very versatile. I think that scares people. If you would like, I will see if our Intellution Analyst is familiar with Maple software. Maybe she can give me some insight that I can forward to you. I have run across many systems that outsource thier programming to companies like Global Technologies out of Arizona. We do ours in-house. On your clarification note, look at the type of values the tables are set up to receive in the FEP. (i.e.- bit, IPRM, PRM, etc.) It helps to find the way data is tranferred. Typically Flags are bits, parameters are either integers or integer parameters. Thanks for conversing. It nice to try and share information on this. Ask anytime.