Hiccuping macro

[jsams]

I have a macro that is designed to run overnight, creating data in a .csv file. Part of the data is latitude and longitude values, generated randomly by two sub-macros, aptly named "Longitude" and "Latitude". The value returned is a decimal variable with six decimal places [padded if necessary]. These two sub-macros are identical in logic, and differ only in the names of the needed variables. The Latitude macro is always called before the Longitude macro runs.

 

This routine has never finished an overnight run in four attempts. At some point, only the macro Longitude generates a script error: "Undefined variable or the variable is the wrong type '%Lon_Seconds%' ... Line Number: 2". This is after this macro has successful runs between 12,000+ and 47,000+ iterations before erroring. The macro never errors at the same time or after the same number of iterations; it seems quite random in its hiccup.

 

Yesterday, I decided to define the offending variable %Lon_Seconds% in the parent macro as a possible workaround for this odd behavior. Last night, the macro Longitude—after 13,004 successful calls—threw an error: No matching "End If". WTF?

 

I don't think I'm looking so much for a solution [since this seems to be a deep and intermittent issue that may not have an easy fix] but more for verification. Anyone else have macros that throw similar errors after many successful iterations?

 

For what it's worth, I'm attaching the code. But if it runs 10,000 times, I don't know why the code seems to go south even though nothing's changed mid-run...

 

<VARIABLE SET INTEGER Option="\x05" Destination="%Lon_Seconds%" Minimum="1" Maximum="999999" _IGNORE="0x0003"/>
<VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon_Seconds%" Variable="%LonSeconds%"/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x03" Value="99999" IgnoreCase="FALSE"/>
<GOTO Name="Done"/>
<END IF/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="10" IgnoreCase="FALSE"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<END IF/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="100" IgnoreCase="FALSE"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<END IF/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="1000" IgnoreCase="FALSE"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<END IF/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="10000" IgnoreCase="FALSE"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<END IF/>
<IF VARIABLE Variable="%Lon_Seconds%" Condition="\x02" Value="100000" IgnoreCase="FALSE"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<END IF/>
<LABEL Name="Done"/>
<COMMENT Value="The integer %Lon% is created in the calling macro."/>
<VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon%" Variable="%Long%"/>
<VARIABLE MODIFY STRING Option="\x06" Destination="%Long%" Value=".%LonSeconds%"/>
<VARIABLE MODIFY STRING Option="\x05" Destination="%Long%" Variable="%Longitude%"/>

[stevecasper]

A few quick observations that may or may not be useful (depending on what the "calling macro" contains).

 

1. The "Undefined Variable" error I used to get all the time when I had Save and Restore variable commands in use. I stopped using them, and stopped getting that error.
   
2. Your "If variable is greater than/Goto" sequence seems redundant, since the random value being generated will never be greater than 99999 (as per the Set Integer command). Though I don't see how this would negatively affect the macro, it just seems unnecessary.
   
3. Your "If Variable is less than" sequences are excessive. The way you have it built, you really only need the one "If less than 10000". No matter what, if it's less than 10, 100, 1000, then it's also less than 10000, and you only need to have one command sequence to establish the 6-digit padding. Again, the extra commands probably aren't going to affect the outcome of the macro, but streamlining can make things easier to trouble-shoot.
   

 

As it is, I don't see any obvious reason for the macro to be failing or erring. Perhaps with the other macros involved, we may be able to see something you could have missed.

[Cory]

I don't' have time to review your code right now but I will tell you I run many macros that run hundreds of thousands of iterations and do not randomly crash. IE there's usually a reason.

 

The most frequent cause of an undefined variable error is an unanticipated percent sign in source data. Percent signs are variable markers so an errant percent sign will cause a misinterpretation. Say for instance I have a macro that files emails and uses the subject for something. It will work fine until I encounter an email that has a subject like "Projections for a 6.3% RoI". It's a sticky problem but you can do a substitution w/o causing it to blow up. But then the problem is putting it back in! I do not know how you are generating the long-lat but you might want to check there first.

 

I don't know what to tell you about the syntax error. What version of MEP are you running?

 

You might try creating a simple reproducible example of this problem to share with us.

[jsams]

1. The "Undefined Variable" error I used to get all the time when I had Save and Restore variable commands in use. I stopped using them, and stopped getting that error.
   
2. Your "If variable is greater than/Goto" sequence seems redundant, since the random value being generated will never be greater than 99999 (as per the Set Integer command). Though I don't see how this would negatively affect the macro, it just seems unnecessary.
   
3. Your "If Variable is less than" sequences are excessive. The way you have it built, you really only need the one "If less than 10000". No matter what, if it's less than 10, 100, 1000, then it's also less than 10000, and you only need to have one command sequence to establish the 6-digit padding. Again, the extra commands probably aren't going to affect the outcome of the macro, but streamlining can make things easier to trouble-shoot.
   

 

1. Nope, ain't be using Save/Restore. There are no values carried from one iteration to the next.

2. I was using the Goto to skip the If/End If statements for values between 100000 and 999999.

3. My duh. Never realized I needed only one If loop to pad the decimal appropriately. Actually, come to think about it, I don't need any If commands...

 

<VARIABLE SET INTEGER Option="\x05" Destination="%Lon_Seconds%" Minimum="1" Maximum="999999" _IGNORE="0x0003"/>
<VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon_Seconds%" Variable="%LonSeconds%"/>
<VARIABLE MODIFY STRING Option="\x0D" Destination="%LonSeconds%" Width="6"/>
<VARIABLE MODIFY STRING Option="\x0F" Destination="%LonSeconds%" ToReplace=" " ReplaceWith="0" All="TRUE" IgnoreCase="FALSE"/>
<VARIABLE MODIFY INTEGER Option="\x04" Destination="%Lon%" Variable="%Long%"/>
<VARIABLE MODIFY STRING Option="\x06" Destination="%Long%" Value=".%LonSeconds%"/>
<VARIABLE MODIFY STRING Option="\x05" Destination="%Long%" Variable="%Longitude%"/>

 

Well, let me run these overnight again and see if this clean macro throws the same horseshoe.

 

Thanks for the feedback on my fat script.

[terrypin]

Anyone else have macros that throw similar errors after many successful iterations?

 

Yes, I've had macros fail erratically at apparently random times. All those occasions I can recall were almost certainly due to conflict with another program. The main offender in my case has been Stiletto, a power utility I've used for a decade or so. It has never been affected by ME Pro, but ME Pro is often affected by it. For important macros so affected I had success by adding commands to stop and restart Stiletto at the beginning and end of the macro.

 

I've never attempted a macro that runs for more than 30 minutes or so. If your are running for hours, isn't it likely that some other process or service could cause a conflict?

 

A longshot, but you might try Event Viewer and see if any of the failure times coincide with warnings or errors, either in the Application or System sections.

 

Finally, one other probably irrelevant thought, but I'll mention it just in case. I'm reminded of it because ME Pro just failed to run the shortkey macro to type my signature for this post. This has been happening frequently since the last version upgrade - really frustrating. It always turns out to be because for some inexplicable reason ME Pro has lots its 'hooks'. Hang on... Yep, I just ran Tools > Restore Keyboard & Mouse Hooks and my shortkey works again. Possibly ME Pro can lose them during your nightly runs?

 

--

Terry, East Grinstead, UK

[stevecasper]

Actually, come to think about it, I don't need any If commands...

Good point!

 

Let us know how it turns out.

 

Something else you might want to do is enable logging of all commands (under the miscellaneous tab in the ME Editor).

 

When the macro fails, you'll be able to pull up that log and see exactly what the last executed line of code was. That can be useful to help catch the faulty command, whether it's the script or some bug within ME itself.

 

Of course, if this macro is running thousands of times in a row, you might want to work something into the macro that deletes the file every so often. Kevin once told me that when that file gets really big, it can adversely affect the macro being logged.

 

Also, errors will often tell you what line broke the macro, but I'm sure you probably already caught that.