Timing issues across multiple PC's

[hpram99]

I've been working around issues with timing for quite some time now, I need to know at this point what the root cause of the issue is.

 

Everyone is using the same coreload on virtually identical systems. There are 30 people using the same macros, about 10 of them right now have issues.

 

The macros run at completely different speeds on different machines, when tabbing through a webpage, it will blast through and skip over the fields it needs to copy to the clipboard.

 

I have forced the configuration to slow down default timing to 300micros for keypress, and 300milis for clipboard

 

I've turned off the high speed timer on all the pc's also, as it was even worse with it on.

 

IE7 Firefox, whatever, doesn't matter what browser, the issue is the macro will run way to fast on these pc's. and if I slow it down any more than it already is, then it gets very annoying for the people that it already works for.

 

Why does macro express run differently on different pcs?

[kevin]

No matter how similar each user's computer is there are still differences. Things like how many other programs are running at that moment, how long their computer has been on, and the equipment used to connect them to the network (switches, hubs, etc.). I once read an article written by a network admin who discovered that a problem with some of their computers was based on the distance away from a switch. A computer would fail in the end user's cube but work fine in the testing lab. In short, there are too many variables to assure that everything is really identical.

 

... if I slow it down any more than it already is, then it gets very annoying for the people that it already works for.

You could set the speed for each computer. Something like this:

Set Variable %T1% to "Name of Machine"

Switch (T1)

 // These computers will work faster than normal
 Case: airpf001
 Case: Computer03
Macro Playback Speed: 2 Times Faster than Normal
 End Case

 // These computers need to run slower
 Case: airpf003
 Case: HRcomputer002
 Case: Sales01
 Case: Acct01
Macro Playback Speed: 2 Times Slower than Normal
 End Case

 // These computers will work at normal speed
 Default Case
Macro Playback Speed: Normal Speed
 End Case

End Switch

This example uses the name of the computer. This example would work if the variability is based on the actual hardware itself. You could, however, use the User Name instead by replacing the Set Variable %T1% to "Name of Machine" command with Set Variable %T1% to "Username".

[rberq]

If your problem is primarily getting fields copied reliably into the clipboard, see a recent topic "Old chestnut - unreliable clipboard copying". Paul suggests, in that topic, setting the clipboard to nulls before doing the copy-to-clipboard, so he can then check (in a repeat loop) for a non-null value to determine whether the copy has completed. He has written a callable macro for that purpose. Because the repeat loop runs only long enough for the clipboard operation to finish, it should in theory adjust automatically for faster vs. slower PCs.

 

I will reply to that topic and see if Paul will publish his clipboard macros for us to try, since I am seeing the same problem you are, though with Citrix screens rather than browser screens. I wonder, for one thing, how he distinguishes between a truly null field that he tries to copy-to-clipboard, as opposed to a copy request that has not completed? Also I wonder whether the copy-to-clipboard is an all-or-nothing operation, or one that may be partially complete. That is -- if I do the clipboard copy command on a 20-character field, wait 10 millisecs, then check the clipboard contents for non-null, then wait another 10 millisecs and check contents again -- is it possible that the first wait will give me perhaps 7 out of the 20 characters, the second wait will add a few more characters, and so on?

[hpram99]

No matter how similar each user's computer is there are still differences. Things like how many other programs are running at that moment, how long their computer has been on, and the equipment used to connect them to the network (switches, hubs, etc.). I once read an article written by a network admin who discovered that a problem with some of their computers was based on the distance away from a switch. A computer would fail in the end user's cube but work fine in the testing lab. In short, there are too many variables to assure that everything is really identical.

 

While I agree that no computer is completely identical, you would assume that a PC that is identical on paper would not have such drastic differences. I really believe this is an issue beyond simple manufacturing variance etc....

 

Just to give you an example, a macro that types "tab" 20 times will work in 1 second on one PC, yet take 8 on another.

 

It's supposed to take 8 seconds. How is it that one PC is so drastically different with the exact same specs as 20 other pc's?

 

If your problem is primarily getting fields copied reliably into the clipboard, see a recent topic "Old chestnut - unreliable clipboard copying". Paul suggests, in that topic, setting the clipboard to nulls before doing the copy-to-clipboard, so he can then check (in a repeat loop) for a non-null value to determine whether the copy has completed. He has written a callable macro for that purpose. Because the repeat loop runs only long enough for the clipboard operation to finish, it should in theory adjust automatically for faster vs. slower PCs.

 

I will reply to that topic and see if Paul will publish his clipboard macros for us to try, since I am seeing the same problem you are, though with Citrix screens rather than browser screens. I wonder, for one thing, how he distinguishes between a truly null field that he tries to copy-to-clipboard, as opposed to a copy request that has not completed? Also I wonder whether the copy-to-clipboard is an all-or-nothing operation, or one that may be partially complete. That is -- if I do the clipboard copy command on a 20-character field, wait 10 millisecs, then check the clipboard contents for non-null, then wait another 10 millisecs and check contents again -- is it possible that the first wait will give me perhaps 7 out of the 20 characters, the second wait will add a few more characters, and so on?

 

 

Good suggestion, I'll look into it. In answer to your question, everything in computing is progressive, but in all reality there is no way to distinguish this as the clipboard will not be available until it's finished with it's initial task of being filled... so really it is all or nothing.

[kevin]

Just to give you an example, a macro that types "tab" 20 times will work in 1 second on one PC, yet take 8 on another.

I often see this sort of thing on the same PC.

[hpram99]

I often see this sort of thing on the same PC.

 

 

It's never am issue with the same PC, the individual PC runs at relatively the same speed regardless of where it is or what it's doing.

 

This seems to be entirely an issue with the way ME calculates delays, it's incredibly inaccurate at this point

[rberq]

hpram99 said, "... the clipboard will not be available until it's finished with it's initial task of being filled... so really it is all or nothing."

 

Agreed. I did some testing:

Initialize clipboard to nulls.

Highlight a long line in a .txt file.

Copy to clipboard.

Repeat 300 times.

If clipboard = null

Tell me it is null

Else

Append clipboard content to T1 variable

End if

Repeat End

Text Box Display of T1 variable

 

With no delay in the loop, each time through the loop checking whether the clipboard was still at its [initial] null value, or had data in it, I never got a partial result in the clipboard; like you say it was all or nothing.

 

In fact, I never got a "null" in the clipboard at all -- even with the clipboard delay set to zero, even with the CPU at 75% zipping a large file, the first time through my loop always had all expected data in the clipboard. In other words, I could not get the Clipboard Copy command to fail at all. This was on two different PCs both running Windows XP Service Pack 2. And yet I have had to add as much as a 500 millisec delay in some production macros, after the Clipboard Copy, to get them to work (mostly) reliably. Inconsistent behavior is the antithesis of how computer software should work. This is why I have jar on my desk, taking contributions to the "Send Bill Gates to Jail" Fund.

[kevin]

I have forced the configuration to slow down default timing to 300micros for keypress, and 300milis for clipboard

We recommend a minimum of 300 microseconds for the Text Type Delay and a minimum of 250 milliseconds for the Clipboard Delay. 300 and 300 are very close to these values. The surprise would be if any computer worked with smaller values.

 

I've turned off the high speed timer on all the pc's also, as it was even worse with it on.

 

This seems to be entirely an issue with the way ME calculates delays, it's incredibly inaccurate at this point

Using the High Speed Timer makes macro commands that rely on timers more accurate. If a computer is inaccurate perhaps it is because you disabled the High Speed Timer. (Yes, I read your comment that "it was even worse with it on.")

 

The setting to enable and disable the High Speed Timer is in Macro Express because we discovered that the High Speed Timer does not work on some computers. Maybe the High Speed Timer is not working on some of your computers.

 

If Macro Express had a problem with inaccurate delays we would have received many reports and complaints through our support department. We have not.

 

To others reading these posts: Is there anyone out there seeing 'inaccurate' delays?

 

The list of possible things that can cause differences in speed is endless:

Do all computers have the same CPU speed? The same number of CPU cores? The same amount of memory? The same amount of free memory? Are they connected to the same switch/hub? How far away is the switch/hub? Are they all running the same network speed? 10Mbs, 100Mbs or 1Gbs? Are they all running the same applications? The same versions of those applications? Are the Windows settings identical? Are they running the same version of Windows? Do they all have the same Windows patches applied? Do any of them have any virus, trojan, adware, or some other virus? Are they all running the same browser? Are they running the same version of that browser? Have all the browsers got the same patches? Have all the browsers got the same security settings? Do some users keep more application windows open than others?

 

[rberq]

Kevin, is the clipboard delay intended to help when copying to the clipboard, when typing/storing data that is already in

the clipboard, or both? See my posting above where I could not get the clipboard commands to fail at all. Here's my

testing macro: copies text to clipboard, instantly pastes it (which always succeeds), and appends any non-null values

to a variable (which also always succeeds). Clipboard delay is set to zero. 10 ms delay within the loop has been

commented out. I fully expected to see problems when running the macro, but I did not, and I don't know why not.

Unless there is something totally dumb in my logic, in which case I will be very embarrassed.

 

<REM2:clear clipboard and working variables to nulls><TVAR2:01:01:><TVAR2:02:01:><TVAR2:03:01:><TMVAR2:16:01:00:000:000:><REM2:when macro is started, cursor should be on a long line of text><REM2:highlight the whole text line so it can be copied to clipboard><TEXTTYPE:<HOME><SHIFTD><END><SHIFTU>><REM2:loop, storing clipboard each time through the loop if it is non-null><CLIPC><TEXTTYPE:<END><ENTER><CTRLD>v<CTRLU>><REP3:01:000001:000001:00300:1:01:><DIS:<IMSD:10><IFOTH2:07:1:><ELSE><TVAR2:02:03:><TMVAR2:07:03:00:000:000:%N1%><TMVAR2:08:03:02:000:000:><TMVAR2:07:03:00:000:000: ><ENDIF><ENDREP><TMVAR2:07:03:00:000:000:**** END ****><TBOX4:T:4:000010000016000998000716:000:Values of T3 Variable%T3%>

[kevin]

// clear clipboard and working variables to nulls
Variable Set String %T1% ""
Variable Set String %T2% ""
Variable Set String %T3% ""
Variable Modify String: Save %T1% to Clipboard
// when macro is started, cursor should be on a long line of text
// highlight the whole text line so it can be copied to clipboard
Text Type: <HOME><SHIFTD><END><SHIFTU>
// loop, storing clipboard each time through the loop if it is non-null
Clipboard Copy
Text Type: <END><ENTER><CTRLD>v<CTRLU>
Repeat Start (Repeat 300 times)
 If Clipboard Text Equals ""
 Else
Variable Set String %T2% from Clipboard
Variable Modify String: Append "%N1%" to %T3%
Variable Modify String: Append %T2% to %T3%
Variable Modify String: Append " " to %T3%
 End If
Repeat End
Variable Modify String: Append "**** END ****" to %T3%
Text Box Display: Values of T3 Variable

[kevin]

In our testing we discovered that some computers can access the clipboard faster than others and on the same computer the minimum time needed could vary. But, a 250 millisecond delay allows the clipboard commands to work properly on the majority of computers. As they say, your mileage may vary.

[johnboy691]

I'm not a technical IT person but here is how I solved the problem. I have internet sites and company green screens that need to be accessed by one macro and copy and/or input data. Due to internet speed, system speeds, etc. nothing was ever static and errors were happening way to much.

 

How I solved the problem was have the macro do a "test" of a particular word or spot on each screen it went to (that I had placed in a loop) before it moved forward. If it didn't find the place it was suppose to be, I had it pause for 10 seconds (that was my choice) but it can be less even miliseconds before looking for the spot again. It does this up to 5 times before I had a display come up saying it couldn't find the spot. This actually made my macro faster because on those places it could just go like the dickens I didn't have to worry about slowing it down overall.

 

What use to take up to four minutes to process a claim and many error outs during the day, is now down to processing a claim in approximately 45 seconds with narry a error out at all during the week because of timing.

 

Just an idea.

[rberq]

Good thinking, Johnboy. I need to do something like that with an application that runs on servers 400 miles away and has unpredictable timing like you describe. The trouble is, it's a Citrix application so it's hard to find text to check because of the way Citrix paints the screen. Have you tried "Wait for Window Title to Appear"?

 

The other unpredictable timing seems to involve drop-down lists, where it might be very fast (or not!) for the list to open. I'm still not sure what happens, but sometimes the macro seems to make its selection before the list is ready to accept it. Any suggestions are welcome!