Variables Dropping, Lighting flipping, and problems, Global Variables. suggestions?

All,

I've been working with a hexagon tech extensively building a program template to globally handle our structure for global editing as we are re-developing our quality systems and tracking capabilities.

Note: 2017 R2 (Service Pack 5) at both locations - Programming offline at desk - Exporting to server - Running at machine

Effectively a program looks like this. (Disclaimer: I'm very much a novice at programming.)
<Initilize>
<Callsub: FormSub; Initial Form> calls the initial form for the operator input
<Callsub: VarSub; Variables> calls the global variables for light, %tol and other misc settings
<Callsub: VarSub; Tracefields> generates tracefields and writes form data to a .txt file to later be read into the part program (Done for future-proofing; ie adding tracefields globally)
<generate header page for report>

<program specific information, file paths etc.>
<program features>
<append report with features>
<save into file structure, if no file structure - create file structure>
<datapage output>
<end>

This is mostly working great. But i have a feeling that my variables are being dropped.

PROBLEM #1:
I have one variable, for parallelism, checking the cut of the sample (aluminium extrusion). The lighting variable values are passing, as well as this one, but this one will not ... sorta. If i write this code in the program
Ex:

<From VarSub>
Assign/Light=80
Assign/Light2=60
Assign/Flat=.4
<From VarSub>

<comment(y/n): FLAT>

Dim(Parallelism) <Parallelism to stage check>

If/ Parallelism.meas>FLAT
<Comment: Re cut sample>
Goto/ENDPRG
End_IF/

Label=ENDPRG

At the end of the program if i hover over the variables all of the correct values are shown. However at my comment prompt, It will show a value of one. (Edit: Incorrectly stated it was returning a Zero value, bad memory, see additional posts.)

PROBLEM #2
(See Attachments, at bottom ) When I write at my desktop, the 'physical' position that PCDMIS writes the light settings --> gets imported differently at the machine.
Ex:
At Desktop reads:
<--,YES,-1,-1,-1,NO,Top Light=<OFF,0,OFF> ,Bottom Light=<OFF,LIGHT,ON>,Ring Light=<OFF,0,OFF>

At Machine reads:
<--,YES,-1,-1,-1,NO,Bottom Light=<OFF,0,OFF> ,Top Light=<OFF,LIGHT,ON>,Ring Light=<OFF,0,OFF>

Almost as if it's reading the string file in a different order. So every offline program requires an edit for this, or I'll have to get used to programming the wrong light settings.

PROBLEM #3
I have a variable for RPT_Path... I feel like maybe this one is something I can do more investigating into. Each program contains the original assignment for this report path. Then an executable file creates a folder for the Tool Copy Number, a sub folder for the year, then a subfolder for the month and saves the file in that location. Right now it is saving it in the original test templates location.

Any thoughts would be greatly appreciated!!!!!!!!!!

Thank you!

Attached Files

Krbrumma over 6 years ago
JEFMAN/vpt.se

PC•DMIS versions are the same, both 2017 R2 Service pack 5. I'm nearly positive that the interfac.dll files are different as we opted with the Optiv Classic(only measuring 2D profiles/price) and it had a lengthy install process in terms of configs. Additionally, I can't boot into Inspect. When we had the config files incorrect it wouldn't boot into PC•DMIS either.

My guess is, since the Classic is heralded as a legacy controller (PC is the controller) and is not often sold, thus less tested and likely most people running it are not running offline and in a complex environment. I have a feeling this may take several efforts to clear up.

I fired off these details to the Hexagon Rep/Tech and they filed a service ticket - they have a feeling it's causing some of the other problems too as well. I'll keep it posted.

As far as the flat assignment, Yes the FLAT="" was changing it. I was doing that on purpose for testing. I tried the rounding theory you mentioned and did not have success, so then I tried setting the variable to =40 and then dividing it by 10 in the main program. Still reset to Zero. Finally, I realized that I should set all of my variables to different numbers to rule that out and discovered it was pulling the value from a different variable. Then I discovered this gem after some time:

$$ NO, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ VARSUB CALL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ASSIGN/LIGHT=0 ASSIGN/LIGHT2=0 ASSIGN/LIGHT3=0 [COLOR=#FF0000][B] ASSIGN/LIGHT4=0 ASSIGN/LIGHT5=0[/B][/COLOR] ASSIGN/ZOOM=0 ASSIGN/ZOOM2=0 ASSIGN/ZOOM3=0 ASSIGN/ZOOM4=0 ASSIGN/PRINTY=0 ASSIGN/SAVE=0 ASSIGN/FLAT=0 ASSIGN/TOLERANCEABOVE1=0 ASSIGN/TOLERANCEABOVE2=0 ASSIGN/TOLERANCEBELOW1=0 ASSIGN/TOLERANCEBELOW2=0 ASSIGN/CFTOLERANCEABOVE1=0 ASSIGN/CFTOLERANCEABOVE2=0 ASSIGN/CFTOLERANCEBELOW1=0 ASSIGN/CFTOLERANCEBELOW2=0 CS1 =CALLSUB/VARSUB,VARIABLESUB.PRG:150.23,LIGHT2,LIGHT3,[COLOR=#FF0000][B]LIGHT4[/B][/COLOR],ZOOM,ZOOM2,ZOOM3,ZOOM4,PRINTY,SAVE,$ FLAT,TOLERANCEABOVE1,TOLERANCEABOVE2,TOLERANCEBELOW1,TOLERANCEBELOW2,CFTOLERANCEABOVE1,CFTOLERANCEABOVE2,CFTOLERANCEBELOW1,CFTOLERANCEBELOW2,,

The Light variables were not all being called equally. So it must be controlled by position rather than by name.

So thank you as your suggestion got the gears turning!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Cancel