New analog input on MKV - IO CFG FAILED Message

Hi everybody.

I´m asking for your help in solving a problem with our MARK V simplex speedtronic turbine. I´m trying to add an analog input signal corresponding to the diesel tank level of the unit (The transmitter is externally powered, it does´nt need power from the card).

I followed the instructions that appear in the GEH6195 manual, and from a flowchart that I found I don't remember where, but I still have problems.
The steps I followed were the following:

- I looked in the SCLEDATA.DATA file to give the appropriate scaling to the signal.

- I wrote the new signal in IO.ASG like this: (I also wrote it to LONGNAME.DAT and TC2KREPT.TXT)

C_C_MAI05 DTKLT PCT ;C -CTBA-049 Diesel tank level transmitter.

- I modified the IO configurator in Milliamp Input Definitions to use signal 5 and set the scaling of the signal (this signal will be only for monitoring, it is not required in the sequence).

- I perform a mk5make command and then an eeprom down user command to core C, all OK.

- I turn off core C with the switch on PD.

I don't know if the steps up to here are correct, but when the control card is turned on again, after status A5 on its display it shows "IO CFG FAILED". The card continues and reaches its normal status A7.

When checking the signal after resetting the station, it is not reflected in the demand display (nor in logic forcing).


If I'm missing information, please don't hesitate to ask.
Many thanks in advance.
 

Attachments

Hello

What about UNITDATA.DAT did you create a new one and loaded into the <I> RAM?

James
Hi James, thank for your reply.

Emmm no, I did´nt know I had to create a new UNITDATA.DAT file, how do I do that?

Neither in the manual nor in the flowchart does it tell me that I should do that for the AI.

I´m uploading pics of the aforementioned flowchart.

THanks!
 

Attachments

Mauricio Marquez,

MK5MAKE.BAT creates a new UNITDATA.DAT when it is run. Check the time/data stamps of the UNITDATA files in the UNIT-specific directory; they should reflect the time you ran MK5MAKE.BAT.

You didn't specifically say that you modified the <C> MA input 05 scaling signal. AND I see in the photo that you modified the <Q> MA input 05 on the TCQA card--which is in <R>.... You need to UNDO that configuration and then go to the <C> MA inputs (TCCA card, if I recall correctly) and find the 05 input and scale it correctly.

What terminal board in the Mark V did you terminate the transmitter wiring on? AND, what screws did you terminate the wiring on? Make sure you are using the correct terminals. SOMETIMES with externally-powered transmitters they are referenced to ground, and sometimes you need to remove or insert a grounding jumper on the CTBA card to isolate or reference the input signal to ground--sometimes it's necessary to use an isolator to get the signal to work correctly, depending on the level transmitter design/construction. Check the Mark V Application Manual, Signal Flow Diagrams, for more information on terminal and ground reference jumpers.

Hope this helps!
 
Hi CSA, thanks for the reply.

Ok I understand, Ill check for the timestamps.

Mmm you´re right, I wrote the signal in the C core in IO.CFG, but modified the TCQA card in IO configurator (actually, it seems is the only analog card that the IO configurator enables me to modify). I will check and reply again.

I used the milliamp input table in Appendix D (I'll upload the photo in case that's not the table to look at) to find out which screws to connect the signal to in the CTBA card (I still haven't connected them).

Do you know about the IO CFG FAILED message on the display? it's another thing that has me worried.

Thanks in advance.
 

Attachments

Mauricio;
On all of our units on all controllers the I/O config. Failed comes on the display for a second before it gets to A7. It has caused confusion before in the past here as usually you only pay much attention to it when your making a change and you think you did something wrong. I don’t think you need to worry about it.
Remember u have to reboot the I/HMI after you make change to signal shows up
 
Mauricio,

HamsterKing is 100% correct. It almost always comes up when rebooting either processor for any purpose as the boot process is going. As long as the processor gets to I/O State A7–everything is good!
 
Mauricio;
On all of our units on all controllers the I/O config. Failed comes on the display for a second before it gets to A7. It has caused confusion before in the past here as usually you only pay much attention to it when your making a change and you think you did something wrong. I don’t think you need to worry about it.
Remember u have to reboot the I/HMI after you make change to signal shows up
Hi Hamsterking, thanks for the clarification about the IO CFG FAILED message, in any case it seems to me that it is very counterproductive that the display shows that message when in reality, supposedly, there are no problems with the configuration, but since you assure me, I will not put more pay attention to that.

CSA, I looked at the timestamps and they correspond to the time that I did the mk5make command, I also made the modification in the IO configurator on the correct card, TCCA of the C core (I deleted the previous one on the TCQA card).
I modified IO.ASG and now I wrote the new signal (DTKLT) on input MAI01.

But now I found another problem, when doing a MK5Make, a message shows me that the signal (DTKLT) is duplicated (points 12E4 and 1A68).
I check IO.ASG, but the only signal with the DTKLT name is the one I wrote in input MAI01 of core C.

In spite of that, I continued with the eeprom down command, shut down the c core, and restart it, as well as the station with the HMI... the DTKLT signal does not exist yet.
What else could be going on? How can I find and delete the duplicate signal?

I'm sending images for you to see.

THanks in advance, It is a pleasure to learn from you specialists.


MAuricio.
 

Attachments

Mauricio,

I am not happy to hear you are struggling with this as much as you are. (This editing of multiple files and configurations is one of the biggest things people dislike about the Mark V turbine control system. It was just a little ahead of its time, and there are many reasons why it is the way it is, but, that's a different thread topic.)

Can you please attach the entire IO.ASG file to this thread? My suspicion is that this signal was already created somewhere in the system files but was unused (there are a LOT of signals like that in Mark* turbine control systems). That is always a risk (not checking to see if a signal name you want to use/create already exists in the system files). I say that because there is a signal DTKLT_AUX--and you said this input was ONLY going to be used for monitoring purposes--so I presume that means it's not going to be used for anything else that would require the DTKLT_AUX signal...?.?.?

The ODD thing here is that in your original post you assigned DTKLT to C_C_MAI05, and at some point that was undone and the assignment was made to C_C_MAI01. I am VERY surprised that MK5MAKE didn't complain about duplicate signal names before, though... Because logical thinking suggests it would have done so when DTKLT was assigned to C_C_MAI05.... So, something does not compute here.

Presuming you didn't create DTKLT_AUX--or the "original" DTKLT--my suggestion is to simply add the number 2 to the assignment in IO.ASG: C_C_MAI06 DTKLT2 PCT

and then run MK5MAKE again to see if it complains again. It shouldn't ... but stranger things have happened.

I haven't read the flow-charts you are using, but in general the steps for adding a signal would be:

--Make the assignment in IO.ASG
--Run MK5MAKE.BAT (with no errors)
[This creates the new UNITDATA.DAT file]
--Stop CIMPLICITY
--Stop TCI (I'm presuming from the displays you have photographed you are working on a GE Mark V HMI running MS-Windows and CIMPLICITY]
--Wait about three minutes
--Start TCI
[This loads the new UNITDATA.DAT file into HMI RAM--necessary for the HMI to be able to display the new signal and value]
[CIMPLICITY should start automatically; if it doesn't do what you normally do to start CIMPLICITY]
--Use the Demand Display (User Defined Display) option to add DTKLT2 to a display to be able to see the value
[You could also add it to the Logic Forcing Display to see the value (it can't be forced, just monitored)]

And, that's as much as I can offer you--because I don't know what versions of software you have on the operator interface so I can't tell you definitively how to get the new signal name into the CIMLICITY project so the signal/value can be added to a CIMPLICITY screen. That's way above my desire to try to explain or work through--getting the new signal/value on a CIPLICITY display. The best I can offer is getting it on to a Demand Display (User Defined Display)--the instructions for this will be found in the original Mark V Users Manual, GEH-5979. Again, it can always be added to the Logic Forcing Display, also.

I'm really disappointed this is being a problem, because it should be easy--but you seem to be encountering just about every possible problem, and that's a bummer. But, this should fix it--with any luck.
 
Mauricio,

".... about the IO CFG FAILED message, in any case it seems to me that it is very counterproductive that the display shows that message when in reality, supposedly, there are no problems with the configuration, ...."

Thinking logically about this (and similar issues) when it comes to Mark* turbine control systems is just not going to make your life easier. Should the message have been something like "CHECK IO CFG"? Yes. But, when you have ivory tower engineers who can do hexadecimal and octal maths without a calculator at the same speed or faster than you and I can do decimal maths, well, they just think differently and their "logic" ain't exactly the same as those of us who don't wear open-toe sandals with socks.... (Yes; a couple of the design engineers on the Mark V wore open-toe sandals with socks every day. And some days, the socks didn't match on one person’s feet, either. True story. Pinky swear.)

One man's logic can be another man's frustration.
 
Dear CSA, thank you for your concern and for your instructions.

I will tell you the whole problem.
The national energy coordinator requires to know the levels of the diesel tanks of all the machines that use, well, diesel fuel to run.

I was asked to add the tank level signal to the MKV of our GTs. This level transmitter is powered from a Yokogawa UM33A digital indicator. This indicator has a mA retransmission signal which I want to use as an analog input to the MK5 panel. Once inside the control, through MODBUS, I think I can send this data to the coordinator through an RTU.

I created the DTKLT_AUX signal just to test an output, along with a COPY block obviously, I have to delete both.
I created DTKLT too, and previously looked up the name in IO.ASG to see if the point name already existed.

I also assign the signal to MAI05 for no reason (it was kind of clumsy, so I changed it to MAI01 after you told me I was configuring a wrong card).

I will upload the IO.ASG file as you requested.

I haven't done the steps you detail in that way... I usually run MK5MAKE, without errors as you say, then the EEPROM DOWN (USER) command, then I reset the cores, and finally the HMI (I don't stop TCI in a way direct). Should I try with the steps you recommend?

And yes, I am working on a GE Mark V HMI running MS-Windows and CIMPLICITY.

I also don't know why I'm having so much trouble with this task.
And if indeed I check if it works through Demand Display and Logic Forcing.

Once again, thank you for your time and wise advice!
 

Attachments

Mauricio,

".... about the IO CFG FAILED message, in any case it seems to me that it is very counterproductive that the display shows that message when in reality, supposedly, there are no problems with the configuration, ...."

Thinking logically about this (and similar issues) when it comes to Mark* turbine control systems is just not going to make your life easier. Should the message have been something like "CHECK IO CFG"? Yes. But, when you have ivory tower engineers who can do hexadecimal and octal maths without a calculator at the same speed or faster than you and I can do decimal maths, well, they just think differently and their "logic" ain't exactly the same as those of us who don't wear open-toe sandals with socks.... (Yes; a couple of the design engineers on the Mark V wore open-toe sandals with socks every day. And some days, the socks didn't match on one person’s feet, either. True story. Pinky swear.)

One man's logic can be another man's frustration.
Hahahaha, I believe you, trust me. I have worked with control engineers from MHI (now MHPS)...and they wore toe socks every day in their office, many with hilarious designs... and as you say, they were on another cognitive level for me (well, Japanese after all).
 
Mauricio;

Your probably waiting for CSA's response. But here is mine.

If you already created an internal point in the logic for DTKLT for testing then that is why the it says the point is in there twice. If you followed your flowchart for creating an internal point you would have entered the point name in factory or site.asg, this puts the point in the unitdata.dat, then you again put the point in io.asg. It now sees the point twice. Just a guess, not sure why the point isn't showing up in your demand display possibly because of this duplication, is DTKLT_AUX showing up in the demand display?
 
Hi Hamsterking, thanks for your reply.

I think I did wrote the point name in SITE.ASG... so, if I write the signal there and in IO.ASG, is it likely to be the cause of the duplicate signal?.
I wrote the signal in SITE.ASG because I have seen some TAs do it (I think in the flowchart that I uploaded, that indication does not appear, neither does the GEH-6195F' manual indicate it).

I have'nt tested if DTKLT_AUX appears on demand display. In the course of the afternoon (I have to check some problems on a SPPA T3000 DCS right now) I'm going to check that, and then I'll delete it and its COPY block from the sequence.

I'll be back with more news.

Once again, thank you very much for your time and knowledge.
 
Dear Hamsterking, you hit the piñata.

As you said, I did write the signal to SITE.ASG, so I deleted it, as well as deleted the COPY block from the sequence along with DTKLT_AUX.

I ran mk5make, and the duplicate signal problem no longer appeared, I continued with the usual process, and finally, DTKLT appeared in Demand Display, as well as in Logic Forcing!!

It was a great satisfaction to have seen how the goddamn signal marked -25%.

I honestly don't think I've found the solution by myself (as I was telling you, I wrote the signal in SITE because I've seen all the TAs do it when creating a new signal, I never would have thought that was the problem). That is why I want to thank you CSA and Hamsterking for your knowledge, time and help in this problem, thank you very much!

Now I have to see and investigate how to access the modbus mapping, investigate the OPC Matrikon, to see how I can visualize and externalize this signal through the RTU.

If I find myself in trouble, I'll probably open another thread to ask for help.

Once again, very grateful for your time!
I learned more than with the manuals.

MAuricio.
 
Mauricio,

Thank you for the feedback!

If you ALWAYS saw TAs make assignments in SITE.ASG, then that means they were creating new signals NOT USED for inputs/outputs. ANY signal name to be assigned to an input or output "channel" has to be assigned in IO.ASG. For the most part, all other signals (except alarms) are assigned in SITE.ASG--like DTKLT_A, --the output of the COPY block. Assigning a signal name is the same as "creating" a signal name--and that can only be done one (a signal name can only be "created" (assigned)) once.

Now, as with ALL THINGS Mark* there are exceptions to every rule (it wouldn't be a GE control system designed and built in Salem, VA, USA, if there weren't exceptions to every rule!).

Anyway, have fun with MODBUS. I never did. NEVER. EVER. MODBUS has caused me more grief than even Micro1-EV fire protection systems--and that's saying something! And, I shouldn't forget CIMPLICITY--or, rather, GE Salem, VA, USA's cobbed method of employing CIMPLICITY. Which is to say it was consistently inconsistent--CONSISTENTLY.

The manuals have some good information--don't neglect them. Are they perfect? I don't think so, but then are any manuals really good these days? (Things change so fast, I think manuals just don't keep up--meaning they aren't kept up to date.) BUT, the real problem with GE manuals is that one division of GE buys the Mark* from another division of GE, and then packages and sells the Mark* with their turbine equipment. Unfortunately, the division that buys the Mark* also employs (or, rather, employed) the division that produced the Mark* to configure and program it for most of the turbines they packaged and sold. And that gave them the FALSE idea that they didn't have to produce manuals that described how the turbine and auxiliaries and driven devices were controlled and protected by the Mark*. And, the division of GE that designed and configured and programmed the Mark* didn't think it was their job to describe how the turbines and auxiliaries and driven devices controlled and protected by the Mark* worked either. In the end, EVERYONE suffers--including the TAs, as well as Customers, owners and operators, and technicians.

And, it ain't going to get any better any time soon.

Did anyone say "divestiture"?
 
Mauricio,

Thank you for the feedback!

If you ALWAYS saw TAs make assignments in SITE.ASG, then that means they were creating new signals NOT USED for inputs/outputs. ANY signal name to be assigned to an input or output "channel" has to be assigned in IO.ASG. For the most part, all other signals (except alarms) are assigned in SITE.ASG--like DTKLT_A, --the output of the COPY block. Assigning a signal name is the same as "creating" a signal name--and that can only be done one (a signal name can only be "created" (assigned)) once.

Now, as with ALL THINGS Mark* there are exceptions to every rule (it wouldn't be a GE control system designed and built in Salem, VA, USA, if there weren't exceptions to every rule!).

Anyway, have fun with MODBUS. I never did. NEVER. EVER. MODBUS has caused me more grief than even Micro1-EV fire protection systems--and that's saying something! And, I shouldn't forget CIMPLICITY--or, rather, GE Salem, VA, USA's cobbed method of employing CIMPLICITY. Which is to say it was consistently inconsistent--CONSISTENTLY.

The manuals have some good information--don't neglect them. Are they perfect? I don't think so, but then are any manuals really good these days? (Things change so fast, I think manuals just don't keep up--meaning they aren't kept up to date.) BUT, the real problem with GE manuals is that one division of GE buys the Mark* from another division of GE, and then packages and sells the Mark* with their turbine eq omegle uipment. Unfortunately, the division that buys the Mark* also employs (or, rather, employed) the division that produced the Mark* to configure and program it for most of the turbines they packaged and sold. And that gave them the FALSE idea that they didn't have to produce manuals that described how the turbine and auxiliaries and driven devices were controlled and protected by the Mark*. And, the division of GE that designed and configured and programmed the Mark* didn't think it was their job to describe how the turbines and auxiliaries and driven devices controlled and protected by the Mark* worked either. In the end, EVERYONE suffers--including the TAs, as well as Customers, owners and operators, and technicians.

And, it ain't going to get any better any time soon.

Did anyone say "divestiture"?
I AGREE!!
 
Top