You are not registered yet. Please click here to register!


 
 
plc storereviewsdownloads
This board is for PLC Related Q&A ONLY. Please DON'T use it for advertising, etc.
 
Try our online PLC Simulator- FREE.  Click here now to try it.

---------->>>>>Get FREE PLC Programming Tips

New Here? Please read this important info!!!


Go Back   PLCS.net - Interactive Q & A > PLCS.net - Interactive Q & A > LIVE PLC Questions And Answers

PLC training tools sale

Reply
 
Thread Tools Display Modes
Old December 28th, 2017, 09:48 AM   #16
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 128
OK, I get it now.

In PB32, you could make a 'bit array' or 'integer' tag as an alarm trigger, with a trigger type of "Bit". On the alarm message tab, you would specify WHICH bit in the array that you were interested in, in the "Value/Bit" column.

In FTV ME, a "Bit" trigger pretty much requires that the trigger be a bit. The "Value" column indicates what the alarm state of the trigger is; there is no selection for which bit one is interested in.

To fix it the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0'. When you find one, go to the Trigger tab and find that trigger. If the trigger type is "Value"?, you're OK -- that's an analog alarm with a threshold. If it says "Bit" for the trigger, then you need to add a new tag that references that bit.

Important: the "Bit" is going to be an offset of an address. If the trigger tag is a bit array, and references N10:42/6, and the value of "Bit" is 1, then it is referring to N10:42/7. Which, of course, you might have moved to N10:137/1, as part of the rest of this exercise.

It's likely that you'll have the other piece of the (former) bit array in your alarm list, but looking at bit 0. So you might want to do some Excel magic, exporting the alarm list and tag DB, and then doing VLookups to determine the data type of your alarm triggers.

You might be able to get away with having the (new) Integer tag as your trigger, and using LSB as the trigger type -- if you know that you can't get both bits on at the same time, of if you do, the 0 bit is the important one that you want to know about. (It would be bad if the 0 bit is "High" and the 1 bit is "HiHi". Using the LSB method, you wouldn't see the "HiHi" alarm as long as the "High" is present, which it likely would be).


That seems to be about it. Perhaps you didn't need to move the array tags into their own integer tags, if they weren't used in a multi-state indicator but only used in alarming; it may have been enough just to break them into their individual bits. Then again, maybe not.

The conversion program is useful, but it's never as simple as "just push a button and it'll work". There's too many differences between the old way of doing things and the new.

Good luck.
  Reply With Quote
Old December 28th, 2017, 01:31 PM   #17
IdealDan
Member
Malaysia

IdealDan is offline
 
Join Date: May 2017
Location: MA
Posts: 207
Quote:
Originally Posted by Aardwizz View Post
OK, I get it now.

In PB32, you could make a 'bit array' or 'integer' tag as an alarm trigger, with a trigger type of "Bit". On the alarm message tab, you would specify WHICH bit in the array that you were interested in, in the "Value/Bit" column.

In FTV ME, a "Bit" trigger pretty much requires that the trigger be a bit. The "Value" column indicates what the alarm state of the trigger is; there is no selection for which bit one is interested in.

To fix it the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0'. When you find one, go to the Trigger tab and find that trigger. If the trigger type is "Value"?, you're OK -- that's an analog alarm with a threshold. If it says "Bit" for the trigger, then you need to add a new tag that references that bit.

Important: the "Bit" is going to be an offset of an address. If the trigger tag is a bit array, and references N10:42/6, and the value of "Bit" is 1, then it is referring to N10:42/7. Which, of course, you might have moved to N10:137/1, as part of the rest of this exercise.

It's likely that you'll have the other piece of the (former) bit array in your alarm list, but looking at bit 0. So you might want to do some Excel magic, exporting the alarm list and tag DB, and then doing VLookups to determine the data type of your alarm triggers.

You might be able to get away with having the (new) Integer tag as your trigger, and using LSB as the trigger type -- if you know that you can't get both bits on at the same time, of if you do, the 0 bit is the important one that you want to know about. (It would be bad if the 0 bit is "High" and the 1 bit is "HiHi". Using the LSB method, you wouldn't see the "HiHi" alarm as long as the "High" is present, which it likely would be).


That seems to be about it. Perhaps you didn't need to move the array tags into their own integer tags, if they weren't used in a multi-state indicator but only used in alarming; it may have been enough just to break them into their individual bits. Then again, maybe not.

The conversion program is useful, but it's never as simple as "just push a button and it'll work". There's too many differences between the old way of doing things and the new.

Good luck.
Aardwiss, You are God sent to me! I have opened more than five Threads on this here but no one was able to put me thru in the right direction like you've just done. Infact I don't even know the Best way to say thank you.

I'm going thru the Alarm now as per your directives.
Meanwhile, How do you normally handle the below errors: (Sorry for asking much please, You've already shown so much kindness, At this point I will be ok with this last questions please)

1. Alarm message Ack option not supported.
2. Screen 2 - GENERAL VIEW: Message display object will be converted to Multistate Indicator object at (224, 88).
3. Screen 3 - 82PK961A_B: Print flag for multistate indicator or message display at (257, 323) not supported.
4. Tag pt502: The maximum value for this tag was invalid and has been set to the maximum valid value based on the tag's data type.
5. Blinking color images are not supported.
  Reply With Quote
Old December 28th, 2017, 02:33 PM   #18
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 128
Quote:
Originally Posted by IdealDan View Post
1. Alarm message Ack option not supported.
I don't know what was implemented in PB32, so I can't know what was being rejected by FTV ME. There is an "ACK" and "REMOTE ACK" tag that you can enter for each alarm, so some sort of "ACK" is supported. Just not in the same way. Read the PB32 manuals, understand what was being done, then read the FTV ME manuals to understand how it manages alarm acks, and then do what's necessary. You need to start putting in a bit more effort here.

Quote:
Originally Posted by IdealDan View Post
2. Screen 2 - GENERAL VIEW: Message display object will be converted to Multistate Indicator object at (224, 88).
Same thing. What was the old object at position 224,88, and what did it do? A "Message Display Object" would display a canned message from a Message Library, based on a tag. Essentially, that's the same thing that a Multistate Indicator is doing. In fact, if memory serves, it links to a common "Local Messages" list. My OCD would sometimes have me edit all my "AUTO"/"MAN" multistates so they would point to the same "AUTO" and same "MAN" item, rather than having dozens scattered throughout the list. Turned out handy when the client wanted to change it to "PROG"/"OPER", and the background color as well -- one-stop shopping.

Long story short: you probably don't have to do anything: this is a Warning, not an Error. But double-check to see that all the messages that were supposed to be displayed by the PB32 display object are being displayed by the FTV ME multi-state.


Quote:
Originally Posted by IdealDan View Post
3. Screen 3 - 82PK961A_B: Print flag for multistate indicator or message display at (257, 323) not supported.
Again, what did it used to do? Was the old PV hooked up to a printer? If not, you probably don't have to worry about this. If yes, then do have a printer? Even then, "not supported" is "not supported". What support does FTV ME have for a printer?


Quote:
Originally Posted by IdealDan View Post
4. Tag pt502: The maximum value for this tag was invalid and has been set to the maximum valid value based on the tag's data type.
Again and again, what was the old value and what is its data type? This may be again a case where you do nothing. An integer data type (link to N10) can't have a value bigger than 32767. Technically, it should allow 65535, but N-type registers are always assumed to be signed.

There are games one can play to get around that, but did he play those games? Did he need to? Only you can answer that.


Quote:
Originally Posted by IdealDan View Post
5. Blinking color images are not supported.
Not supported is not supported. There might be ways around that -- overlapping objects with competing visibilities based on time, or some such. But is it worth the effort?
  Reply With Quote
Old December 28th, 2017, 02:58 PM   #19
IdealDan
Member
Malaysia

IdealDan is offline
 
Join Date: May 2017
Location: MA
Posts: 207
So much insights, Wao! Thanking you with a capital lettered THANKS is not even enough. Honestly, earnestly and immensely, I really appreciate.
Aardwizz, I'M GRATEFUL!!!!!!!!!!!!!!!!!!!!!!!

I may contact you should in case I meet a serious pot hole on the road, meanwhile can I be opportuned to have your email or skype? dan247humble@yahoo.com is my email address.
ONCE AGAIN 'THANK YOU SIR' !!!!!!!!!!!!!!!!!!!
  Reply With Quote
Old December 28th, 2017, 11:23 PM   #20
IdealDan
Member
Malaysia

IdealDan is offline
 
Join Date: May 2017
Location: MA
Posts: 207
Dear Aardwizz, From your statement;
''In FTV ME, a "Bit" trigger pretty much requires that the trigger be a bit. The "Value" column indicates what the alarm state of the trigger is; there is no selection for which bit one is interested in.
To fix it the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0'. When you find one, go to the Trigger tab and find that trigger. If the trigger type is "Value"?, you're OK -- that's an analog alarm with a threshold. If it says "Bit" for the trigger, then you need to add a new tag that references that bit.''


NOW, In PB32, all the values in 'Alarm messages' tab are 0 (value/Bit column) But in FTV ME, all the Trigger values are 1. Since you said, ''To fix the error, scroll through the FB32 message tab, and look for anything where the value ISN'T '0' ''
WHAT NEXT SHOULD I DO TO RESOLVE IT NOW THAT THE REVERSE IS THE CASE PLEASE?
I remain grateful to you

Last edited by IdealDan; December 28th, 2017 at 11:35 PM.
  Reply With Quote
Old December 29th, 2017, 08:19 AM   #21
Aardwizz
Member
United Kingdom

Aardwizz is offline
 
Aardwizz's Avatar
 
Join Date: Dec 2017
Location: Swindon
Posts: 128
You really need to start getting a better understanding of how both PB32 and FTV ME think. That's what you're being paid to do, after all. And starting next week/month/year, my idleness/spare time/internet access will be over, and I won't be able to help you.

As near as I can tell (and we're entering into a "I'm making this all up, but it sounds right" zone here), in PB32's "Value / bit" column, it was asking, "If the trigger is a "value" type, what value am I looking for; if the trigger is a bit type, what bit am I looking for?"

From what you say, all your triggers are Bit-type, and the alarm manager is only caring about the "0" bit.

Which is great, and makes life easy. Of course, if your trigger is an integer (perhaps formerly a bit array), then looking at "Bit 0" might not work in FTV ME, since it really wants all of it's Bit-type triggers to have tags that are actually boolean bits.

That's why I suggested exporting everything and using Excel magic (the VLookup spell) to easily analyze whether your trigger tags are bits or integers.

I don't have any PB32 manuals (you do -- use them) so I don't know if it assumed for bits that '1' was always the alarm condition, or if there was a configuration somewhere in the trigger or message where the alarm state was defined.

But it doesn't matter. In FTV ME, the conversion tool assumed/evaluated that '1' was always the alarm state. That column, unlike PB32, doesn't care about bits, it just wants to know what value means "alarm".

It could be that the message you got was just a warning, that a feature that MIGHT have been used is no longer valid. If so, since you never looked at anything other than bit '0', there's no other action that you need to take.

It also could be that it detected that one or more of your triggers were non-bit tags, and that looking for bit '0' won't work anymore, because any bit in that word would trigger an alarm. In that case, you need to know which trigger tags are non-bit ones, and perhaps create a new trigger based on that bit not word. Finding that out is again that Excel magic.
  Reply With Quote
Old December 29th, 2017, 09:32 AM   #22
IdealDan
Member
Malaysia

IdealDan is offline
 
Join Date: May 2017
Location: MA
Posts: 207
Aardwizz, You have been GREAT!!!!!!!!!!!!!!!
I really Appreciate your time and kindness/willingness to help me.
  Reply With Quote
Old January 3rd, 2018, 07:34 AM   #23
IdealDan
Member
Malaysia

IdealDan is offline
 
Join Date: May 2017
Location: MA
Posts: 207
Happy New year to you Aardwizz and to all of us here!!!

Please I just need to be sure of something;
After editing all my plc programs, I moved to Factory Talk to link the addresses to appropriate Tags, Those Bit Array Tags of PanelBuilder32 converted to memory Tags, and no link connection for linking them to plc addresses, But selecting 'Device' on FT ME Tag Editor solves it. I want to confirm if it is the actual thing to do?
Attached Images
File Type: jpg Screen Shot.jpg (56.0 KB, 15 views)
  Reply With Quote
Reply
Jump to Live PLC Question and Answer Forum

Bookmarks


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Topics
Thread Thread Starter Forum Replies Last Post
Index Integer Bit will not hold a value? a11anjones LIVE PLC Questions And Answers 0 December 8th, 2009 06:02 PM
fishenguy fishenguy LIVE PLC Questions And Answers 54 November 13th, 2007 08:33 PM
Migrating VB6 IDEA app to VB.Net Extrasoft LIVE PLC Questions And Answers 5 November 4th, 2007 06:13 AM
Flags, Tags, industry terminology and acronyms. FORGETFULL MEMBER LIVE PLC Questions And Answers 7 February 16th, 2005 03:59 PM
Latch a Bit then Bit Shift Left jthornton LIVE PLC Questions And Answers 2 August 22nd, 2003 06:35 AM


All times are GMT -5. The time now is 11:56 AM.


.