Passing Variables back from a Subroutine?

[MrComment]

Im trying to pass some variables back from an external Subroutine to My active program.

Seems that I can pass variables to the Subroutine rather easily but for some reason I've not been able to figure out how to get it to work in reverse for me yet?

Hum, I suppose I could gleen the data I need from a Dimension also.

Anyone have any examples of sending Dimensions or Variables from a Subroutine into the current part program?

Thanks again

[craiger_ny]

Once you set your part program object to the current part program you use the .SetVariableValue method. You have to first declare an object to set using the GetVariableValue method.

This is not really a .bas just an example of what you need to do it.

Dim objApp As Object
Set objApp = CreateObject("PCDLRN.Application")
Dim objPart As Object
Set objPart = objApp.ActivePartProgram
Dim objOutTol As Object
Set objOutTol = objPart.GetVariableValue("NUMBEROUTTOL")  'where NUMBEROUTTOL is a PCDMIS part program variable
objOutTol.LongValue = 1
objPart.SetVariableValue "NUMBEROUTTOL", objOutTol  'this sets the variable in the part program to 1

[MrComment]

Thanks Craiger, but I was wondering if there was a way to do it without having to use VB?

According to my PCDMIS manual I should be able to pass variables back and forth via the assignments declared in the arguments list of the PCDMIS CallSub function?

Who knows maybe it just another PCDMIS bug. I'm coming to expect every dang-nabed thing I try to do in the flippin software is bugged, broken or just impossible.

[craiger_ny]

Sorry I thought you wanted to pass back and fourth between a script. Thinking back to your other post I guess you want to pass back and fourth between your sub that is within your PCDMIS part program, is that right? Kind of a lousy feature that it won't set the variable in the .prg even though the sub is in the .prg. I am stretching it a little here because like I said in my last post I don't do this but does it do it like VB does with a function like being able to declare ByRef or ByVal? Or possibly do you have to create a variable that has scope throughout the entire .prg kind of like a public variable in VB. I'd think they would want to follow that type of thinking with PCDMIS.

I'm glad you are bringing this stuff up though these are questions no one else has asked.

Craig

[MrComment]

I have a "Free State" program that measures certain features which I can't access easily with the CMM when the part is bolted to the "Part Fixture". I also wanted access to may CAD model in either of the Fixturing conditions.

So I decided to create a seperate program for my Free State senerio and when my part is bolted to the "Part Fixture".

Now that Im this far what Im trying to do, is have the main application (the one with the part bolted to the fixture) first prompt the operator to load the part on the free state fixture. After calling the free state subroutine in an external PCDMIS part program file it does its business and finishes. Then the program prompts the operator to load the part on to the Hard Fixture and the main program resumes.

Meanwhile somewhere in the app I need to figure out how to gain access to the dimensions or the feature related data that just finished executing in the Free State program. This way I can have PCDMIS seemlessly put all of the info in one beautiful and magnificent report at the end.

Apparently I should be able to do all of this ("and more! ") with PCDMIS but my syntax must be in error when I try to actually get the data back from the subroutine once it is finished.

[James Doolittle]

For the win


Edit --> Preferences --> Setup --> General --> scroll down to the very bottom --> Make Variables Globally Visible CHECK YES

[cmmguy]

thanks, james - I thought I saw that somewhere when I was looking for something else...

You would think that would be ON by default.

[MrComment]

Also, "Pass back setting from Subroutine" should also be default I think.

After trying both of those additional settings and running the app through completely I still havent figured it out 100% yet.

I can see where it measured the features with the subroutine in the graphics display window. But I cant dimension them because they dont show up in the feature list. Also Im not sure how to access any of their settings.

For instance after I run the app and say I add:
ASSIGN/V10 = CIR8.D

CIR8 being an Auto Circle in my external subroutine, CIR8.D is shown red in my code.

So near as I can figure once the app ends the "global" variables are gone, and the circles shown in my graphics display window is just some sort of bogus data points I cant access.

Either that or I'm forgetting some sort of special sytnax or something.

Anyway trying to figure this out has taken longer then just writing my Plan B code. Which is writing the XYZD data for these circles to a txt file, at the end of my subroutine. Then have my calling app read the values out of the txt file and place them all into generic features, which these I can dimension.

[cmmguy]

Are there possibly some settings local to the subroutine that are inhibiting the return of the data?

[James Doolittle]

Try this:


ASSIGN/ V10 = "CIR8"


V10.Diameter should then be the measured dia of CIR8.

[MrComment]

I tried setting the Global variable option in the external subroutine program also(probably makes more sense that way now that I think about it), but it still didnt work.

Also:
ASSIGN/V10="CIR8"

returns:
CIR8

The only work around Ive found is to save everything to a text file, and then read it into generic features in my main app. With a little trial and error I got it pretty well seemless looking now. With one minor exception.

My Feature labels arent connected with my features on the screen???

[bobcavallo]

You can assign the measured result to a variable and obtain the data that way.

ASSIGN/V1=LOC1.Z.MEAS

[MrComment]

Ha finally figured this stupid thing out....

Using a Pointer to Reference Data
Often when you access an attached part program , you will want to use data from that part program. When referencing this data you must reference the pointer (or variable ) that contains the location of your part program.

Consider an example:

Suppose you're attaching TEST_A.prg to your current part program. Your attach command would look something like this:

CS1=ATTACH/C:\PCDMISW\TEST_A.PRG, Machine=

EQUATE/LOCAL ALIGNMENT = A1, ATTACHED ALIGNMENT = A1

Notice the pointer, CS1. You will use this pointer to extract data from the attached part program.

Now, suppose you wanted to display the measured X value for feature F1 from TEST_A.prg inside your current part program. You would use a statement like this
COMMENT/OPER,"The X value for F1 from the attached part program is:"

,CS1:F1.X

The code, CS1:F1.X, essentially tells PC-DMIS to look at TEST_A.prg, find feature F1, and display the X value. This is the way pointers are referenced inside PC-DMIS.

PC-DMIS also lists features from an attached part program in the Construction or Dimension dialog box. PC-DMIS will display the attached part program’s ID pointer within the Feature List box. A plus sign (+) appears to the left of the pointer. Clicking this plus sign expands or collapses a view of all the features in the attached part program. After you expand the view to show all the features of the attached part program, you can select any of those features to use in the construction or dimension process.

Note: You can not select the attached program’s pointer. Only the expanded IDs associated with that pointer can be selected.

I needed the little CS1: to make the syntax correct.

I tried CS1. and of course that didnt work, but the colon makes it work like you would expect.

Why is it you always find this stuff out after you stop looking for it?

[SABarber]

ATTACH is not the same as calling a SUBROUTINE. ATTACH does not execute the program that is attached - only uses the values when the ATTACH was executed.

[cmmguy]

SA,
Can you explain that further?
Why would you attach a program that you do not wish to execute and why would you use features from that program if theywere not relevant to what is currently measured.

Mr Comment,
Did you attach and then execute the subroutine? What you pointed out makes sense because in VB you would have to reference the form and then the object on that form to get the value.