Can anyone advise where an enumerated state command is defined within the MKV? To allow the command to be utilised in a user defined display, the right most charachter of the flags column (in Unitdata.dat) must be "B". Yet if the the signal is defined in site.asg (as ;VQ), then this value equates to "1" which cannot be used in user defined.

Please advise

 

We have MKV with <I> interface and our enumerated information is in the ENUMDATA.DAT file located in the unit directory. Hope this helps.

RichT88

 

RichT88,
Thanks for the reply. We have configured the enumdata.dat file and have this cross referenced within site.asg, yet with this configuration the respective bit in the flags column in UNITDATA.DAT is not set to "B" as is required.

Thanks
martinc

 

RichT88, Until we get some hard information about what this person is trying to do, there's nothing to be done.

If he's not willing to share the details of what he's trying to accomplish (signal names, etc.) then it's useless to respond.

He needs to tell us exactly what he's trying to do, what he's done, and forget this *&@% about "B" in the flags column, because when it's properly configured (and it's certainly not) the "B" ain't gonna get set.

We can't read his mind.

 

<p>Dear CSA,

<p>Thanks for the reply.

<p>With regards to your comments...

<p>We are trying to create a user defined display, which will start/stop, fans/motors/pumps, etc. without the requirement to go to the MCC and manually start them. We are aware that this could be done through a graphic or via logic forcing, but the preference is currently to use a user defined display.

<p>We have configured a user defined display and a CMDSTATE BBL, the signal names SC43MTR and SS42MTR have been assigned to the command and the status of the BBL. The Enumdata.dat file has been configured and all has been run through (successfully) a MK5MAKE and has been download to an offline panel.

<p>However, when we do this and attempt to use the signal SS43MTR within the user defined display, when we "Check Form" we get "Not a Command".

<p>Now having checked the maintenance manual (GEH5980E), it states;
<pre>
4-11.3.1. COMMAND TYPE POINTNAMES. Command target additions must be made from the available command type
pointnames found in the UNITDATA.DAT file (see Figure 4-37). Using your ASCII text editor to view the file, the rightmost
character of the seventh column of the file, Flags (Hex), contains the code which identifies the pointname command
type. The codes for the command types are as follows:
2 - <B> point, pushbutton command
3 - <Q> point, pushbutton command
4 - <B> point, logic state command
5 - <Q> point, logic state command
6 - <B> point, analog setpoint command
7 - <Q> point, analog setpoint command
A - <B> point, enumerated state command
B - <Q> point, enumerated state command
For example, in Figure 4-37, the signal CA43ISL (Cable Remote Isochronous Setpoint Lower) is a pushbutton command in
<Q>. The right-most character/least significant bit of the Flags column value for the pointname is " 3 ". Pointname
CSRGVAUT is an invalid point for use as a command target. Its Flag code is a " 1 ". Only Flag codes appearing in the table
above are valid command pointnames.
;
; Name No.
; <> <-->
#unit_data GT 1
;
#point_data
;
; Memory Offset (Hex) ------------------------------------+
; Memory Segment (Hex) -----------------------------+ |
; Flags (Hex) --------------------------------+ | |
; High/low limits type -----------------+ | | |
; Plotting limits type -----------+ | | | |
; Scale code type ----------+ | | | | |
; Point type ---------+ | | | | | |
; Point Number -+ | | | | | | |
; Name | | | | | | | |
<----------> <---> <-> <--> <--> <--> <--> <--> <-->
CA43ISL 480 001 0002 0000 0000 0003 0060 01E0
CSRGV 4363 002 0011 0000 0000 0007 0060 1216
CSRGVAUT 4788 002 0011 0000 0000 0001 0060 1568
L43BW_CMD 535 001 0002 0000 0000 0005 0060 0217
SC43 4354 009 0002 0000 0000 000B 0060 1204
Figure 4-37. Part of UNITDATA.DAT Showing Different Command Types
</pre>
<p>Now we have the following set up:
<pre>
Site.asg;

;MOTOR TEST SOFTWARE
?VQ SC43MOTOR ENM19
?VQ SS43MTR ENM19
?LQ L43QA_START LOG
?LQ L43HQ_START LOG
?LQ L43QB_START LOG
?VQCC SC43MTR_MSK HEX
?LQPB L43MTR_START LOG
?LQPB L43MTR_STOP LOG
?LQ L1 LOG
?LQ L2 LOG
?LQ L5 LOG
?LQ L6 LOG

Enumdata.dat;

#enum_data 19 19 9 0000 #?????
0000 # 1234
0000 # AUX LUBE OIL PUMP
0000 # AUX HYD OIL PUMP
0000 # JACKING OIL PUMPS
0000 #????56
0000 #????57
0000 #????59
0000 #????60
</pre>
<p>If the GE Maintenance manual is correct, then the the flag bit needs to be set as "B" within UNITDATA.DAT, yet with our configuration the following is seen within UNITDATA.DAT.
<pre>
;
; Name No.
; <> <-->
#unit_data T1 1
;
#point_data
;
; Memory Offset (Hex) ------------------------------------+
; Memory Segment (Hex) -----------------------------+ |
; Flags (Hex) --------------------------------+ | |
; High/low limits type -----------------+ | | |
; Plotting limits type -----------+ | | | |
; Scale code type ----------+ | | | | |
; Point type ---------+ | | | | | |
; Point Number -+ | | | | | | |
; Name | | | | | | | |
<----------> <---> <-> <--> <--> <--> <--> <--> <-->
SC43MTR 5406 009 0020 0000 0000 0001 0060 1A3C
SC43MTR_MSK 8087 015 0042 0000 0000 0009 0060 2F2E
SS43MTR 5407 009 0020 0000 0000 0001 0060 1A3E
</pre>
<p>As you can see the flag bit is a "1" which is not a valid command type.

<p>I hope this clarifies the situation and what we are trying to achieve. Please advise if you are aware how we can get this point configured such that it can be utilised within a user defined display.

 

Well, this is an interesting case. I'm going to have to take some time and think through how this might be accomplished in the way you are proposing. It seems easy enough at first glance, but what you are proposing is fairly complicated. This is going to take some thought and time; please be patient.

 

Dear CSA,

I have noted some discrepancies in what I posted, this is due to me copying data inaccurately.

With regards to the signal names:
On the CMDSTATE BBL, the signal names SC43MTR and SS43MTR (Not SS42MTR as I had posted earlier!)

In Site.asg The first line is actually:

;MOTOR TEST SOFTWARE
?VQ SC43MTR ENM19 (Not SC43MOTOR as posted earlier)

Regards,

Martin

 

CSA,

Would it be easier to make a new dynamic display rather than using the Demand Display? I never use the Demand Display for anything other than just displaying information. Anytime there are going to be controls I always make a new display from scratch.

 

When we have information, we can be of help. It's likely as thought, a configuration issue, which is preventing the proper flag bit from being set.

Even if you used graphic displays for accomplishing this, you would still have to write some logic like you are trying to do. You can use this same logic on a graphic display once you get it working on a User Defined Display.

I can see several issues here.

First, lets consider an example of the Generator Control block.

From a "generic" FACTORY.ASG file:

?VQ SS43GEN ENM13
?VQAS SC43GEN ENM13
?VQCC SK43GEN HEX

So, the "state" value, SS43GEN, is a <Q> Variable; the "command" value, SC43GEN, is a <Q> Analog Setpoint Variable, and the Command State BBL Mask value is a <Q> Control Constant Variable.

From your SITE.ASG file,

?VQ SC43MOTOR ENM19
?VQ SS43MTR ENM19
?VQCC SC43MTR_MSK HEX

SC43GEN, and in your case, SC43MOTOR, are the "command" inputs to the Command State block. They will have integer values (hence the "AS" Analog Setpoint requirement) and when the target is clicked on the operator interface will refer to ENUMDATA.DAT to determine what mode (or motor, in your case) will be "enabled".

SS43GEN, and in your case, SS43MTR, are the "status" outputs of the block. They will have integer values, and when the operator interface sees the integers, it will refer to ENUMDATA.DAT and display the appropriate text values.

And you say you are using SS43MTR as the "command", yet it's only configured as a variable. SC43MOTOR should be the command, and it should be a <Q> Analog Setpoint Variable ( ?VQAS ). I'd be willing to bet that once you make this small change, that SC43MOTOR will have the proper flag. You should be using SC43MOTOR, not SS43MTR, and it should be configured as a ?VQAS, not just a ?VQ.

I have a couple of very important questions and comments. You seem to want to drive the Aux. L.O. and Aux. Hyd. pumps with this logic. Those signals are generally drop-out to run, and modifying the rungs to be able to run those motors (which are "critical" to start-up and shutdown) is rather dangerous and would be somewhat difficult. Are you planning on blocking this manual logic during unit operation (to prevent starting the pumps with this logic when the unit is running)? Or are you planining to start/stop the motors at any time, when the unit is running, or when it's shut down?

The rungs/logic for driving these motors have been around, literally, for decades and use what GE refers to as "drop-out-to-run" logic, not the usual pick-up to run most people are accustomed to seeing (because of the critical nature of the motors). Generally, these outputs use N.C. (Normally Closed) contacts to start and stop the motors they control, so the logic signals need to drop out to close the contacts to start the motors and the logic needs to pick up to open the contacts to stop the motors.

Are you planning to wire a spare contact output in parallel with existing outputs to start the motors?

Also, since you are listing jacking oil pumps, I'm wondering if this unit is an F-class machine, in which case the Aux. L.O. pumps must be running all the time because there is no shaft-driven Main L.O. Pump, so one would not want to stop these motors when the unit was running.

I mean, it's your unit and you can do with it as you please, but these are critical motors that should be running at very specific times and I'm not clear how you would be starting and stopping these motors with this logic. And that's all I'm going to say about that.

I'm not clear about how you've configured the rest of the command state block, though. What have you set your command state mask to? What are the permissives and presets set to? What are you trying to do with the command state block and the logic push-buttons? I would think it would be enough to select a pump, and if the permissives were met and there were no presets active that the logic output for that pump would go to a logic "1". I'm presuming that L43QA_START is the output from the block for the Aux. L.O. pump and that if you set SC43MOTOR to the value for the Aux. L.O. Pump (1) that with no presets active and the permissive for this output that it SS43MTR would change to 1, and AUX LUBE OIL PUMP would be displayed for the value of SS43MTR, and that L43QA_START would go to a logic "1" and that you would use that signal to start the Aux. L.O. Pump.

How will you run both pumps at the same time (necessary for stroking hydraulic actuators) with this logic? What's the L1, L2, L5, and L6 for?

You could just use a ?LQLS for each spare output command, write a "1" to make the state go high when you want to start the pump, and a "0" when you want to stop the pump. That way you could run multiple pumps/motors simultaneously, something you're not going to be able to do easily with a command state bbl.

Hopefully this helps. I would discourage the complexity involved with a command state block and enumerated data. As you've already seen, it just takes a small configuration mistake to cause a lot of grief. Good luck with your endeavor!

 

RichT88, It's a matter of personal preference. You seem comfortable with developing animated item list displays; many people are just terrified of them and find them extremely confusing. Most people seem to have the idea that if they make a mistake, that the turbine is going to blow up. Far from it, and I've seen people who've finally gotten over that fear develop some stunning displays.

User Defined Displays are even something most people think can also trip the turbine if they make a mistake, and that's also not true. I'm pleased to hear that you're not afflicted with this unfounded fear; most people won't even use

User Defined Displays to monitor turbine operation. I've been to sites that have been running for more than ten years and there isn't a single new display (User Defined or animated) on the operator interfaces. They try to do all their troubleshooting with the Logic Forcing Display.

Me, I'm about getting a task done quickly.

I venture that if they get the logic working, they will eventually try an animated display. I've seen people who try to develop an animated display and logic at the same time spend days and days trying to get them both to work, and in the end, just give up on the whole effort. They seem to have this idea that unless it's graphical, it's useless, and that's just not the case.

Everyone has their own style and their own preferences. Right now, he just needs to get the logic working any way he can; then he can put it into an animated display. I was just pleased to see that he was trying to create a User Define Display with targets, because as I said, most sites don't even do that!

 

<p>Hi CSA,

<p>I am a colleague of Martin's and have been working with him on this software.

<p>We have tried configuring the input as a ?VQAS and it failed to work. The value of the point was changing as required but the CMDSTATE block failed to respond to any value set. However we have managed to get it to work now, but we have achieved this by editing a file in the PROM directory. By modifying points in UNITDATA.TPL that appear to be spare with the lines below, the block now functions correctly. I don't know if this will be the final answer to configure this, we have a good TA on site now that will be having a look at this, but I am guessing that the answer/approval for this modification will have to come from CM&U.
<pre>
SC43MTR 4366 009 0019 0000 0000 001B 0060 121C
SS43MTR 4367 009 0019 0000 0000 0001 0060 121E
</pre>
<p>To answer some of your other questions and concerns I will take a step back and try and explain from the start what we are trying to achieve.

<p>Our production/operations dept. have requested a display for remotely operating pumps, fans, etc. to eliminate the risks arc flash from operating switchgear locally.

<p>We started looking into this and there are quite a few pumps, fans, etc. that we needed to operate (around 16 I think). As I am aware that there are limitations of the numbers of each point type that can be configured (we have already hit our limit on constants and are having to reuse ones that are already defined, but unused) and that I haven't configured and CMDSTATE block before, I thought I would try and be a bit clever. Instead of configuring up to 32 ?LQPBs, I would try and configure CMDSTATE blocks to select a pump to control and then use one start and stop button to operate the selected pump. The software is latched so that pump selection can be changed to operate other pumps, but still allows any running pumps to continue to run. The output of these rungs would then be used in the main pump control rungs. In the case of the pumps that use the drop-out to run, it would be the last contact before the coil allowing the rung to be broken to start the pump. In the case of pumps that require a logic state of 1 to run, our logic would bypass other control logic to basically force the pump on. This software will only start a pump that is not required by the system, it will not stop any pump that is already running, as I agree with your concerns that it would be difficult to achieve and would also be dangerous for the unit. This logic is planned to be operational with the unit on and off load. If you still have any concerns with this I would appreciate hearing them.

<p>The CMDSTATE block has been configure with the mask set to FFFF to allow all inputs to function, although this probably can be changed for the presets as they have been configured to LFALSE. All the permissives have been configured with LTRUE. The logic points L1, L2, L5 and L6 were just points that were thrown in as presets to try and force the block to change when I couldn't get the block to work from the command input. These have now been removed.

<p>The software is now configured more or less how we want it and the command state block is working fine. It has been fully tested as we have the luxury of a complete spare TMR MKV panel in the office at our disposal, so none of the messing about with prom directories has been anywhere near a running unit.

<p>None of this will be implemented without GE approval, but we do like to go to GE with our own ideas first.

<p>Also to answer another point, the demand display was just for testing, an animated displayed has now been created and works fine.

<p>I have not configure any ?LQLS points before how do these work? how are they different from an ?LQ.

<p>Does anyone have a list of maximum points that can be configured for both A and B panels? As I am sure I have seen this somewhere before.

<p>Thanks for all you comments.

<p>Simon

 

Thanks for the feedback! It's the most important contribution to control.com.

I'm only repeating what's been said before on control.com: Files in the PROM subdirectory should never be edited without GE's approval or direction. It's not a recommended practice. That's all I'm going to say about that.

As far as running a modification by CM&U, they generally don't respond to such requests. And neither will the PAC. If you want a modification, they will provide a quote. But, generally they won't approve or disapprove modifications that customers want to make themselves. Too much liability, as I'm sure you can agree with in this litigious world we live in. Nothing makes an owner or his insurance carrier call their legal representation faster than a force outage or catastrophic damage, and lawyers are always looking for the deepest pockets to blame.

I've never been really clear about how many "spare" enumerated data points are available in a Mark V or how to configure them. They're kind of like scale code/types, but they don't appear in a .SCA file. They're kind of odd signals. The Mark V is full of stuff like this: exceptions to every rule. It can be very maddening, as in this case.

You said you tried configuring the point as a ?VQAS and it changed stated but the CMDSTATE block failed to respond. Does that mean that when you configured the target on a User Defined Display that it didn't complain about not being a command when it was configured as a ?VQAS? If so, I would venture that some other issue was still present at the time (the mask or the perm's or presets, etc.); but that's just a guess.

Spare logic states are command logics that, when a "1" is written to the point and all the permissives are satisfied (if any exist) for that command logic, it will go to a logic "1" and will stay a logic "1"; in other words, it's "self-latching". Similarly, if a "0" is written to the command logic, it will go to a logic "0" and stay at logic "0". Command pushbuttons on the other hand, will only stay a logic "1" for the time the signal is being written to and then they will return to a logic "0".

They are used sparingly in most CSPs, and not at all in some.

I don't know if I've ever seen a numerical limit stated anywhere. It would kind of depend on the number of arrays in use, the number of double words, etc. I think the only way we know if a limit has been reached is when MK5MAKE.BAT is run and errors are written to MK5MAKE.LOG by one of the executables in the batch file. Usually, a good indication that you're very near the limit is when all spare process alarm signals are all used!

 

Hi CSA
Your comments regarding the prom directory totally I agree with. The mod was only carried out as a test in our test panel, I would never do it in the actual unit without approval.

As we are in a maintenance contract with GE any software mods that we would like to implement have to be approved by GE via our CPM. This usual involves CM&U and a hefty price tag for them to fully test it, but on occasions the CPM has sought approval from a TA who has been on site for minor mods. We usually try and come up with our own proposals for software mods as I have been told it is cheaper for them to rubber stamp our ideas than get them to design it for us, it is also something I enjoy doing.

The spare points I am just interested in for all signal types. We have hit our limit on constants and I have got figures for the maximum number of constants (1812 constants in a "A" panel (series 5 & 6 gas proms) 2044 constants in a "B" panel ( gas "B" proms) - 2556 constants in "B" panel (GHD prom sets)). I would be interested in finding what we have used and what we have left. I believe some information like this is given from the new version of MK5MAKE on HMI’s from the DDLOCATE program. I did receive new a version of this from a previous CPM and was informed they would work on <I>, but they didn’t.

I wasn’t involved with the testing of the ?VQAS before, so I could not answer your question, so I decided to configure it again to see for myself. This time it works fine.

Thanks for the suggestion of the ?LQLS, these also work great, a lot less logic involved to implement the mod. Only the one ?LQLS required in the main pump rung to break or bypass the other logic. We just now need to decide which method we would like to implement.

The method using the CMDSTATE block looks nicer on the graphic and requires two actions to start any pump, but is restricted as there are only 8 outputs on the block, so multiple CMDSTATE blocks would be required to operate all pumps, fans etc.. The ?LQLS option is simpler and would required additional logic if any permissive are required, but doesn’t look as nice on the graphic due to the number of buttons that are required.

On the subject of permissives, I have been told it isn’t advisable to run the Jacking oil pumps with the unit at full speed, so we will prevent this from happening. Are you aware of any other issues with starting anything else? I am guessing not as the oil pumps would cut in anyway based on system pressures and most everything else runs anyway with the unit on. The only ones that don’t usually run on load are the flow divider and the AA booster.

Thanks you comments and suggestions it is greatly appreciated.

Simon