FTViewME Edit memory string tags at runtime

I have a list of names that are stored in string tags that I need to be able to edit at run time. There is a control list selector that chooses the name, and there are three values associated with it. The values are stored in the SLC, but the name is a memory string tag marked retentive.

Is there a way to allow the user to edit the name from the Panelview 700+? I am having trouble figuring out how to edit a particular string tag using a single edit name screen. Can I pass the string as a parameter to a separate display?

I am using FTViewME 5.10, but the destination PV+ is running v 4.0 firmware.

Thanks,
Paul

I'm guessing you don't want to create a String Input Enable object for each name in the list, or is that not what you mean?

Yes, I want to have one object that the operator can touch that will allow him/her to edit the presently selected name.

It is basically a recipe system, but not using the built in recipe plus stuff. I am considering changing it to the recipe plus system, but I am a bit leery of that since I have never used it and generally don't trust the FTView features outside of the very basic things...

Well, I was going to post a screenshot with a better explanation, but FTView decided to hose my display, so I guess it's time to reboot again.

They should ship this software with a 40oz. speaker magnet, so when you get really frustrated, you can just strap it to your hard drive and walk away...

At least it's not the new PV Component system. PV Explorer or whatever that damned thing is called.

I just got to play around with a PV Component 600 Color touch. The thing can be connected by USB to your computer, but nstead of using one of the other softwares, it has it's own web based version stored on the PV itself. It's slow as hell, (takes something like a minute every time I try to open the page to edit the screens), and has loads of communication problems (constantly dropping communications, causing the web based software to boot me out.) and was a pain in the *** to get connected to in the first place.

Who decided to create a driver specifically to access a USB device through TCP/IP? They deserve to be hit by a bus.

/rant

Sorry I don't have anything specific to say on topic, but I figured this would be as good a place as any to rant about how much of a pain AB made that thing.

Well, I got lucky this time

and did not have to reboot...

It would be a two step procedure, but I think you could use a macro.

Create an input string enable button with a buffer string tag - use this to enter your new name. Condition the visibility of the macro button with there being a new string in the tag. The macro button will be your "Accept New Name" button.

In the macro editor there will be a list of all Name tags.

Tag
strrecipe1

Expression
if (ControlListValue = 1) then NewName else strrecipe1

and so on for each item.

This should only change the list item you have selected. Having said that, I would make sure the operator couldn't scroll through the list once they start to change a name. A cancel button would be a good idea to clear the NewName tag.

If you try this please let me know if it works.
Or put the strings in the SLC...

Thanks, Sinc, I will give that a try.

We did it with a little help on the PLC side. The 'notification' tag for the string entry object was used. Unfortunately on the PLC side, as indirects to strings weren't allowed, it was a long subroutine with as many rungs as locations with a compare to the current selected on and the appropriate copy command. Not pretty but it works.

Thanks, Bernie.

I am trying to avoid using string tags in the PLC. I have another system with a PV standard in which I have recipes based on SLC tags, and when I tried to display more than about 5 strings on the same screen, it really bogged down the communications. I ended up just displaying the selected recipe title, and the previous and next ones in my lists, and added some logic in the SLC to do the copying from the real list to those display objects. Luckily, it's a 5/04 that does support string indirection or that would have been a real nightmare.

Unfortunately, A/B doesn't give us much control of the method and timing of tag updates with either platform.

I am going to try the method Sinc_Green recommended and will post results.

Paul

Can I expect Macro buttons to work when I perform a test just on the display on my machine (development PC)? I don't want to test the whole application here, because it will cause a conflict with the one that is actually running (display status and control tags are used among other possible problems).

Nope. You have to test the application.

The above suggestion worked after I added another element to the end of the macro.

BufferName = BlankString (which is retentative, memory, and empty)

to clear the buffer when the operator pressed the button.

Sinc_green said:

Nope. You have to test the application.

Click to expand...

You'd think that information would be readily available in the help or the knowledgebase...I did finally find it in the user's guide...

I will try to run a test early in the a.m., before production starts tomorrow, so I can ensure that I don't screw up a batch of sausage.

Thanks again for you valuable input.

Hey, I stripped out all the potentially harmful stuff and went ahead and tested it and it worked. I did not understand what you meant by:

The above suggestion worked after I added another element to the end of the macro.

BufferName = BlankString (which is retentative, memory, and empty)

to clear the buffer when the operator pressed the button.

Click to expand...

I was able to edit several of the names, including the last one. I tried to pre-load the tag (RecipeSetUp\EDIT_STRING) to be edited with another Macro Button, but that did not appear to work, and there does not seem to be a way to preload the input buffer with the existing text within the pop-up keyboard anyway...sometimes, you gotta just say "good enough". It's way better than having to download a new app every time they want to edit the names...

Thanks again.
Paul

Cool.

Here's what I meant by that statement - and it all depends on how you set it up:

I wouldn't want the macro button always there because it would clear or update the currently selected name if the operator accientally pressed it. As I said earlier, the way I did it with a similar app was to make the macro button visible when the "buffer string" is not blank (after the operator has used the Input String Enable). Ideally the macro button would then go away when it was pressed, having fulfilled its purpose.

If the last act of the macro is to empty the "buffer string", the operator would be back to square one. I did this by having the "buffer string" populated with another string tag which was always empty.

Okay, thanks for that clarification. I did some more testing today, and I did find that my EDIT_STRING would hold onto the value last entered, so it wasn't quite right to edit one name, then scroll down and choose another recipe from the list, then edit it and find the other name there already. so it was beneficial to add a step to the end of the button macro to assign the value of EDIT_STRING to my new NULL_STRING. I also went ahead and did the conditional visibilty on the macro button based on EDIT_STRING<>NULL_STRING, so now it all looks and works great.

Thanks so much for your help with this.

Paul