Factory Talk View Studio Import issues

We have a PV standard application written by others which I must convert to run on a Panelview plus.

There are about thirty tags which generated errors during the import, example:

"Tag V_V_TL2: Bit Array tags are not supported. Tag will be converted as a memory tag."

Most of these tags appear to be used to animate an object with two to four states by using two bits.

In the pva file, the tag would be set up as a bit array with a bit level address and an array length of two (one of them uses three bits).

So how would I accomplish this in a PV+? How can I make a tag equal to the value of two (or three) adjacent bits in SLC memory?

I have told them (the boss) I could finish the conversion in about 8 hours, ( so, I have all day tomorrow ) to work through the hundred or so errors logged by the import. After looking at the errors log, I may have been too optimistic...The most worrisome parts are all the errors with string tags and alarms...

I wish I had anticipated this failure and prepared a Crimson app...too late now the machine is down and must run Thursday.

Any help and advice appreciated.
Paul

OkiePC said:

We have a PV standard application written by others which I must convert to run on a Panelview plus.

There are about thirty tags which generated errors during the import, example:

"Tag V_V_TL2: Bit Array tags are not supported. Tag will be converted as a memory tag."

Most of these tags appear to be used to animate an object with two to four states by using two bits.

In the pva file, the tag would be set up as a bit array with a bit level address and an array length of two (one of them uses three bits).

So how would I accomplish this in a PV+? How can I make a tag equal to the value of two (or three) adjacent bits in SLC memory?

I have told them (the boss) I could finish the conversion in about 8 hours, ( so, I have all day tomorrow ) to work through the hundred or so errors logged by the import. After looking at the errors log, I may have been too optimistic...The most worrisome parts are all the errors with string tags and alarms...

I wish I had anticipated this failure and prepared a Crimson app...too late now the machine is down and must run Thursday.

Any help and advice appreciated.
Paul

Click to expand...

Paul,

Unfortunately it looks like you may be S.O.L. here. In FTView you can reference bit positions in an array of words, but not at the memory tag level, only as direct references for alarm triggers. For example the syntax "{::[Shortcut]B3:0,L5}" would point to words B3:0-B3:4, and then you could use trigger values 1-80 to point to bits B3:0/0 through B3:4/15.

I don't see anywhere that you can use these bit positions as object references, though. It looks like your only option may be to create new tags at the bit level for each state of each object you need to define.

A PITA I know, but I'm sure you expected nothing less, right?

Hopefully someone else will come along and correct me here and show you an easier way to do what you're wanting to accomplish.

Good luck,
Dustin

After a quick glance before clocking out, it appears most of them can function with the single bit state. At least the first two are for features that may or not be installed, so they have two "invisible" states, an ON state and an OFF state. I will make all those we don't use unconditionally invisible, and just use the single bit on or off state in the PV+ objects for those features installed on our machine.

I think I hammered out the comms. All the tags were created with a shortcut named "clx". I am stuck with that, huh?

I fixed the first of about 30 references to bit arrays that got converted to internal memory...you'd think they would at least import the mapping and fault/flag it with a bogus shortcut, but I am digressing...

I think I can hammer through those thirty odd tags, then I have to deal with the string arrays.

I believe I can run the machine without making all the string arrays work.

We have a PV1250+ supposed to be a drop in replacement coming in the a.m.

I think in the morning I am going to crack the case on the old one, perhaps its something simple or swap-able at a board level.

The long term plan is a G310, but the last one I converted (30 screens, 1200 tags) took most of a week to get done. This one only has about 15 screens, but they are busy, and about 800 tags...This one uses bitmaps for most all indicators, so they should drag and drop right over...

I've used a mask and bit-shift to handle Bit Arrays that came from old RIO projects. Let me take a look and see if I can find an example of those expressions.

Now I remember. You use an Expression in FactoryTalk View, with both a Bit Shift Right operator ">>" as well as a Bitwise AND operator "&".

Get out some graph paper; you're going to remember a lot of masks and get used to offsets that are in the quantity of bits, not the "bit number" or "bit position".

Let's say the tag was called "PounderStatus" and bit positions 10 and 11 were used to provide a value of 0, 1, 2, or 3. Let's say the value is 2 (10 binary), but there are a bunch of other bits in the word.

The Expression driving your multi-state indicator will be

{[CLX]PounderStatus} >> 10 & 3

PounderStatus = 0111 1000 0011 0010
PounderStatus >> 10 = 0000 0000 0001 1110
PounderStatus >> 10 & 3 = 0000 000 0000 0010

Can't I just make it:
2 * ({[clx]N105:91.11)}) + {[clx]N105:91.10}
?

Perhaps to enforce bool interpretation in the expression:
2 *({[clx]N105:91.11} == 1) + ({[clx]N105:91.10} == 1)

I don't know if that is the correct syntax and would expect to replace those PLC bit references with their correct tag names.

But, then can I make that expression the very definition of a tag value source as in crimson?

I did a PV conversion years ago that I had to do this. I remember that there was a tech note on this. I'll see if I can dig it up.

There are probably a handful of ways to do it.

I think that Bit Shift and Bitwise AND are simple for the terminal to perform, and its how I set myself up with a cheat sheet and a pot of coffee.

Also: be sure the source Tag is of datatype Integer or Unsigned Integer; if you leave it as (Default) the terminal will assume it's a Floating Point value and won't let you bit-shift it.

Tags in FactoryTalk View can be Digital, Analog, or String types. There is no "Bit Array Little Endian" like there is in Crimson 3.

Today I've been switching back and forth between doing a PB32->Crimson conversion and doing a native FactoryTalk View application. It certainly makes me appreciate some of the ControLogix integration that FTView does really well (live runtime error reporting !), but it also makes me grit my teeth at all the things that I think Crimson does better or more flexibly.

I have the SLC code I can change too (as long as I do it before asking permission).

I should just unpack those bits and make them integers like a normal person would have done in the first place. There's plenty of memory to do this, then I can just change the existing tag to reference INTs. The tag names are all based on the German language, so I really don't want to have to add 30 new ones in my naming style

German programming is by default the most efficient and stable programming, ja ?

You could use the Tag Substitution feature to replace references to the Tag with a reference to the Expression. That should save you a lot of searching and typing.

Well, it looks like all of those bit array tags were imported as memory tags but the tag type is set to analog (and grayed out). I supposed I must delete the tags and recreate them to make them digital tags?

I still don't know what to do about the alarms' "Remote Clear All" and "Remote Ack All" tags. I copied the "Remote Ack All" into all of the alarms' "Remote Ack" fields, but I am not sure that it's going to work as expected.

Some of the strings appear to have converted correctly and others didn't.

On the bright side, we have replacement (standard) hardware on the way to be delivered any moment now, so I may be off the hook for this conversion today.

Refurbished Standard panelview was delivered a few minutes ago, so I am off the hook for the conversion...for now...

Paul