I've attached a document that describes a parametric part measurement program. The document only covers PC-Dmis code, not the C# PC-Dmis Automation code used to create the subroutine file described in the linked document.
One of the hardest thing about PC-Dmis Automation is trying to figure how to use it. I figure if I post enough stuff about PC-Dmis, something might be just the thing that clicks for a user.
All of the applications I've used PC-Dmis Automation and C# can be condensed down to performing the following tasks from a C# application:
Starting and stopping PC-Dmis.
Handling the event when a user stops the measurement program.
Choosing and executing a PC-Dmis measurement program.
Handling the event when PC-Dmis completes a measurement program.
Handling the event that indicates a Dimension command was just executed.
Receiving from PC-Dmis the Dimension command and processing in real time the Dimension info while measurement program is executing.
Creating an executable PC-Dmis subroutine program from C#.
Writing PC-Dmis assignment commands into a PC-Dmis subroutine program.
C# as an aid to writing parametric measurement programs.
My posted document above is an example of the last three items in the above list work in a PC-Dmis program. The C# code to do the stuff in the list is posted else where in this forum.
I've been asked why I use C# and not Visual Basic. First of all, I don't have a particular religion when it comes to a programming language. I started writing code in 1977 when the TRS-80 Tandy computer first came out. Since then, I've written code in most of the common languages as well as a few '3rd generation' languages used within an application (like Cypress basic in PC-Dmis). I originally began exploring PC-Dmis Automation using Visual Basic 6, which was pre-Visual Basic Studio. I was coming along pretty good and had already figured out how to do the first half of the list above when my French counterparts said I must stop with the Visual Basic because it was going to be obsolete. Even though I argued that it was actually being folded into Visual Studio, they insisted so I said fine and switched to C#. Having done so, I admit that to me, the C# code seems to be less verbose and a little easier to follow.
The other why for using C# is because PC-Dmis has a lousy developer environment. I was minding my own business, developing code for automating the production of CNC part programs in CAD/CAM when the company I was working for decided to switch from MM4 to PC-Dmis. The guy writing MM4 measurement programs was about to retire and had no interest in learning PC-Dmis, so the company decided, let's have Dave do it. Most of the MM4 measurement programs were highly parameterized and fairly complicated. I first learned to program MM4 then began the process of re-writing them in PC-Dmis. The so-called MM4 to PC-Dmis translator only worked for the most simplest of MM4 programs. The PC-Dmis code was getting quite bloated with code to handle the parameterization process, not to mention the somewhat lacking debug tools. When you then add the measurement reporting code, the whole process was just getting bogged down. Luckily, I stumbled across this thing called PC-Dmis Automation. It didn't take long to figure out I could shift all the work of data processing, file processing and reporting to C# and use PC-Dmis for the task of moving the Probe safely around the part and take hits and create dimensions. C# does the rest. A side benefit was realized when we discovered we could make a better User Interface in C# for the CMM operators and hide the PC-Dmis interface into the background.
