Using FPTR

[Sean Harris]

I have been using the FPTR command to open a COM port and write out variables to another computer. Until now things have been swell. I have 1 PC that is "dropping" communication. I dont know if its an error or a time out. My question is this, in the FPTR command when you select the COM port how or what is initialiazing the COM port? I ask because the communications seem to re initialize when you choose another COM port ( in the program ) and then change it back.

PC dmis 3.5mr2 Win XP sp2 Global Image DEA controller. 5'8" ,225lbs ,Brown eyes, Shaved head, Leo

[craiger_ny]

Are you sure this is called FPTR? FPTR is PCDMIS's default name for a file pointer (used in I/O, ie file/open, readline etc). We use comm to offset machine tools but run a script.

[Sean Harris]

yeah something like this.


FPTR =FILE/OPEN,COM3,WRITE
FILE/WRITELINE,FPTR,V1
FILE/WRITELINE,FPTR,V2
FILE/WRITELINE,FPTR,V3
FILE/WRITELINE,FPTR,V4
FILE/WRITELINE,FPTR,V5
FILE/CLOSE,FPTR
close

Does Pc dmis initialize the COM or is it a windows function.

[Underspec]

Windows controls communication ports. If you have a firewall that could be the reason your dropping. I would ask your network admin.

[craiger_ny]

Hey Sean,

Care to share what you are doing and what your application is? We are setting up to communicate with a machine tool in one case (already are in this case) and CMM PC to a PC to lathe. We are using script that is 3rd party so I don't want to violate what they did for us but it is not being done the way you are communicating (like I said they scripted it). But I'd be curious what you are doing. In a nut shell I am here to suck up information. Care to give us a description of your application if you can. It looks like something I may be able to apply.

Anyway, I am not sure how the writeline function behaves compared to the printline function but there may be a difference. I'll check the help file. I know in VB writeline uses quotes around it and printline does not. This might make a difference in how things are declared on the receiving (client, I think that is the case with what you are doing) end. Is it possible the code is different on the PC that is giving you a problem, even if it is a type declaration? Or have you had good luck in the past and this problem has cropped up? I probably don't have much to offer if it is the later except I'd ask if someone has changed that PC's serial port settings. This is out of my realm as it is something I am not currently putting to use right now but you have sparked my curiosity. Go with underspec over me on this one for sure, but if that isn't it who knows......

Craig

[LynnA]

Morning Sean,
We use the FPTR command within PC-DMIS to write to a Com Port as well.
What we have discovered, is Windows XP likes to "shut-off" com ports it "thinks" you don't need. Normally this occurs when when the PC is rebooted or something else, other app takes or tries to take control of that COM port. What we have done for a work around, is use hyperterminal, we establish communication with the correct com port, with the correct settings, and save the file to our start-up folder, every time the machine boots up the com port is initialized, Basically all we do is the following:

FPTR =FILE/OPEN,COM3,WRITE
FILE/WRITELINE,FPTR,LOC23.Y.MEAS
FILE/CLOSE,FPTR

We use COM3 as it is actually a USB to Serial Convertor, Works well. On our other machines we use Com2, old software default / habit.........

Hope that helps
Lynn

[craiger_ny]

Oh shoot that reminds me of a problem we had with communication over com. We communicate with an Ovation Engineering EZ-Comp. For reasons unknown we could not do it with the PC that came with the CMM (probably a driver issue) if we connected to Hyperterminal the string looked fine as it went over but EZ-Comp would not recognize it. Like I said we never figured out why but everything worked fine when we went from serial to USB=>serial like Lynn A.