Symbol Action, unresponsive on busy page


Recommended Posts

I have a set of simple start and stop buttons.

The Action is set to quick sequence and are very basic Pasturizer_Master_Start[0]=0 & Pasturizer_Master_Start[0]=1

Now i have copied the buttons to a blank page and they operate almost instantly.

on the page in question with lots of active graphics the start normally works fine.

once the machine is running and the screen update is busy with all the changing variables, then the stop button is very slow or doesn't work at all.

I switch screens to the blank page with a copy of the buttons and the stop is instant.

I suspect this is a result of the screen draw time and the quick sequence running in the same thread as the screen draw.

The page is only set to update rate of 1/s so i'm guessing its the amount of symbols and values on the page causing the problem.

i have a similar response to any popup windows that are called for on the same page.

 

is there any way i can show thaw page draw time on the runtime licensed machine to verify if thats the issue.

Also do you have any other suggestions without creating a sequence for every button command.

Communications is via OPC with the updated DLL, its almost as if DF is so busy updating all the graphics on the screen the OPC Write gets missed or dropped.

 

Link to comment
Share on other sites

Yeah, it sounds like the screen draw is tying things up.  The click message will be delayed while the paint message is being processed.  There isn't a built in way to see redraw times in Runtime.  You can see it in development mode in the status bar.  One option in runtime would be to put a component on the bottom (Order -> Move to Bottom) and put in its OnPaint event:

global startPaintTime = systime()

Then create another component that you put at the top (Order->Move to top), and in its OnPaint event put:

global totalPaintTime = systime() - startPaintTime

Then you can use a variable value component to display the totalPaintTime variable.

This only works on non-overlaid pages.

Link to comment
Share on other sites

ok, so its is a resource issue.

My development the screen draw time maxes at 200ms, on the runtime we max out a 850ms when all objects are active.

so the next question is how do make sure the Quick Action or the event on the buttons work correctly.

One thought was to simply load the command into a string then call a function or begin a sequence that executes the command string.

this would require quite a lot of work but thats my first thoughts.

Upgrading the on site hardware isn't really an option, we run a Quad 2.14 ghz IP69K Stainless Steel HMI.

now performance could be lower than normal as i am viewing via VNC so that is additional work.

With the piece of equipment stopped the draw time is 400ms. 

 

Screen Shot 2020-11-20 at 7.38.50 PM.png

Screen Shot 2020-11-20 at 7.39.39 PM.png

Link to comment
Share on other sites

Yes, almost certainly.  Windows only processes messages one at a time within an app as it is all done from the primary thread.  If your screen is taking a long time to draw, then it will be sluggish to process other things like mouse clicks.  Mouse move for the cursor is different and won't be sluggish.  Any mouse move processing in DAQFactory will be if you have slow pages, but the cursor will still move quickly.

I would try and figure out why the page is so slow to refresh.  I'd just look at the refresh time and start deleting components.  My guess is that you have one, or maybe a few, components that are taking all the time.  Once you figure that out you can look into why and fix it.

Link to comment
Share on other sites

Most of the components are very heavily loaded and consist of multiple symbols and rules


shape for the background with multiple conditions and rules

value with blink based on status 
text status, from any array. 
fill graphic based on value 

plus other items. 
off loading to a sequence to process the command string might be the way to go. 

Link to comment
Share on other sites

Ok, so offloading the command to a sequence doesn't really solve the problem as the click is often missed.

so im back looking at my graphics.

Question about processing time.

Between Split Colors & Color threshold is there much processing time difference ?

i would suspect that split color is probably the most intensive but by how much.

That screen currently has 20 Objects that utilize split colors.

i was thinking of changing to color threshold, or simply 3 different symbol options Green Closed / OFF, Yellow mid / active ,  Green Open / ON

Link to comment
Share on other sites

I would have to look at the source and then make an educated guess.  A simpler way is to simply try deleting these components and see how much it improves the screen draw time.  If you are missing clicks your screen draw time must be very long so it should be very obvious what is causing it if you just slowly start deleting components until it speeds up.

 

Link to comment
Share on other sites

Ok, just a Update.

I have stripped the screen back and still IDLE draw time is 300ms, Active (Machine Running ) is 450ms.

Now my button action is loading the required command into a string.

I have a sequence monitoring the String length and then executes the string if the length >1.

The first thing i noticed is the string did not always populate from the button action especially if i was using the mouse up action.

When i changed the button to Mouse Down the string always gets populated.

As the sequence returns the string to once executed i can verify that first the command is loaded into the string, and secondary the string has been executed.

The 'Master Start' & 'Master Stop' channels are only read in the PLC and control a group start sequence.

When the machine is running and the screen is busy the String Command does get cleared (So its Executed) but the OPC Tag stays TRUE not the String Command's target of FALSE.

if i then switch to blank page with the buttons also on the stop command works fine.

I'm confused how a Execute command running in a sequence can be effected by the screen re-draw activity.

I'm going to change the priority of the Sequence to see if that helps.

 

 

Link to comment
Share on other sites

1st, I would look for why a blank screen takes 300ms to draw.  That tells me you have some CPU intensive scripts.

2nd, though this may not be the case here, Mouse Up is not always received by DAQFactory.  For example, if you Mouse Down on something, then move your cursor outside of the DAQFactory window before releasing the mouse button, the Mouse Up message may not be received.

3rd, we have found an issue with some object oriented blocking that can cause things to run slow.  Basically if you call myObject.memberFunc1() which takes a while (for example doing I/O) it will block access to that object. Then if somewhere else, say in the UI, you try and call myObject.memberFunc2(), or even access a variable: myObject.memberVariable, it will have to wait until the first function is complete.  This may be the source of your slowness.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.