Driving PC-DMIS with VB-written User Interface

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Driving PC-DMIS with VB-written User Interface

    In 2009 we contracted Hexagon to create a Graphic User Interface (GUI) for our PC-DMIS CMMs. They used Visual Basic 6. The interface works pretty well, although I want to improve anything I touch.

    2014 we have the first of several new CMMs for an expansion of the same product line, so we want to replicate as much as possible from 2009. So, I try installing the GUI from 2009 onto the new CMM. I have had to make some modifications to get the GUI to read its own database, so the GUI ain't what it used to be. Neither is Windows: the GUI was created on WinXP, and now we are in Win7.

    Here is today's problem: the VB program creates an object of the PCDMIS app. The GUI program does what it's supposed to... Asks the operator which part, lot number, other information. Click the Measure button, and after verifying ID and password, the CMM starts to inspect the parts. PC-DMIS is running, but not visible.

    While the PC-DMIS part program is running, none of the GUI controls function. Click on any of the GUI windows and nothing for a few seconds, then "This action cannot be completed because the other application is busy" dialog box.

    Anyone else out there driving a CMM this way?

  • #2
    There were some pretty big updates to the .NET framework from XP to W7, including OLE. My GUESS - I'm sure you aren't allowed to go sharing that source code with anyone, so my GUESS is that the OLE calls in the source code are no longer (syntactically) correct. Maybe the method or class changed. Maybe the computer it is running the custom GUI on needs to have the previous .NET versions installed on it (my machine had big problems after 'upgrading' from XP to W7 for that very reason). Does the computer running this GUI have the necessary VB libraries installed? Has the installed version of PCDMIS changed? What about the support files (dll, dat, ini) for the GUI, could those have been corrupted or are missing? What registry keys are required for the GUI?

    What I'm getting at is that there are A FREAKIN ZILLLLLLION things that could be going on here and you need to get on the line with the guys that wrote this API for you or find another equally qualified programmer to start combing it over and debugging.

    Debugging something of this scope is IMPOSSIBLE without access to the source code. Even then the probability for a 'quick fix' is slim to none.

    IMO - replicate the technology you're using for the new CMMs, i.e. - WinXP PC's, same version PCDMIS, and just keep them the **** away from the internets. It wasn't broke before, so why not just keep using it as long as you can? Manager types are always trying to 'upgrade' and improve - which is great, unless you're the poor schlob who has to go around fixing and troubleshooting all this new tech that never ever works like it should, and then after all is said and done you have the same functionality as before so what was the point.

    Computers run on logic. Managers should take note.

    Comment


    • #3
      Subscribed.

      Comment


      • #4
        My job is developing applications such as what you describe, and I have to say that Frazz is mostly spot. Prior to moving all of our CMMs to 7 from XP, I rebuilt our PC-DMIS automation on the .NET 4.0 framework instead of 3.5, which meant hundreds of hours of debugging and code review. I say 'mostly' because of one exception: you can probably save yourself the trouble of installing additional versions of the .NET framework since VB6 predates all of them.

        To start, make sure UAC (User Account Control) is disabled on the new computers. If you're in a domain environment, this should likely be done anyways by group policy, but it's worth checking. UAC has been known to not play nice with VB6.

        With that said, the message you are receiving is an indication that the calls being made by your GUI are timing out or are being rejected by the server application (PC-DMIS) without being executed. Basically, the GUI told PC-DMIS to perform a task that may take a not-insignificant amount of time, and while that process is still busy you are trying to send it new commands. The common recommended action I have seen is to set the request timeout property of the COM instance to a ridiculous interval like this:

        Code:
        app=CREATEOBJECT("PCDLRN.Application")
        app.OLERequestPendingTimeout = 9999999
        This is basically the "sweep the problem under the rug" approach, in that it just masks the symptom; instead of the "server busy" message appearing the default timeout period of 5 seconds, we're making the application wait ~16 minutes to notify you that the request has not been processed, at which time we're hoping the task has completed and the application has moved on to something else. The more appropriate solution is wrap the calls to the server application in Backgroundworker processes; the GUI can remain responsive while the process is running, and calls to PC-DMIS when it's busy can be caught inside the GUI in a more graceful manner without ever being pushed on to PC-DMIS. Unfortunately, this is not simple task.

        Now, for the big kicker: why do you get this message in Windows 7 and not Windows XP? I'm not exactly sure. It's not like the timeout property should have been changed without you knowing. Aside from the message box, is the GUI exhibiting a significantly different behavior? When PC-DMIS is executing on your existing systems, does sending more commands from the GUI make it do something else or are they seemingly ignored?
        (╯°□°)╯︵ ┻━┻

        Comment


        • #5
          Originally posted by JohnJackson View Post
          Here is today's problem: the VB program creates an object of the PCDMIS app. The GUI program does what it's supposed to... Asks the operator which part, lot number, other information. Click the Measure button, and after verifying ID and password, the CMM starts to inspect the parts. PC-DMIS is running, but not visible.

          While the PC-DMIS part program is running, none of the GUI controls function. Click on any of the GUI windows and nothing for a few seconds, then "This action cannot be completed because the other application is busy" dialog box.
          Are you sure this worked differently when you used XP?

          If the VB program calls .EXECUTE on a part program, nothing should happen until the .EXECUTE call returns (PC-DMIS finished running the pp). During this time, the VB UI would be frozen. The alternative is to call .AsyncEXECUTE and handle all the PC-DMIS events to know when execution is finished - in this case the VB UI is responsive, but that doesn't guarantee that PC-DMIS will 'answer the phone' when additional calls are made to it. It depends on what you are calling - if it is safe to do during execution. Maybe the PC-DMIS automation interface has been 'tightened up' to remove the possibility to give it conflicting orders during execution?

          Exactly what action(s) are you trying to perform on PC-DMIS while the pp is running?

          Edit: And if the VB program is calling DoEvents anywhere 'to make the UI responsive', almost anything can happen - it's a sure recipe for problems...
          Last edited by AndersI; 07-02-2014, 04:45 AM.
          AndersI
          SW support - Hexagon Metrology Nordic AB

          Comment


          • #6
            "IMO - replicate the technology you're using for the new CMMs, i.e. - WinXP PC's, same version PCDMIS, and just keep them the **** away from the internets." -Frazz
            -You're preaching to the choir! But it's not my choice... corporate overlords say XP is obsolete. But then, if I had my druthers, I'd still be working in MM4. Also, in complete agreement about the zillion freakin' things it could be. I only need to find which one. Problem is we've got more Win7 machines coming, and corp says the old XP machines gotta go.

            ewe, Andersi: thanks, food for thought and I'll try and report back.

            "Are you sure this worked differently when you used XP?" -Andersi
            No, I'm not sure. In fact some of non-functioning functionality was quite the same. With the original XP system the main GUI window is unresponsive while the program runs. A CMM control window, running as a separate process, provides the Hold, Continue, Stop controls, and those respond accordingly, sending the commands back to PC-DMIS. My first pass with Win7 the separate process did not respond. Since then I placed those controls onto the main form which is of course the same process.

            More later...
            Thanks

            Comment


            • #7
              Originally posted by AndersI View Post
              The alternative is to call .AsyncEXECUTE and handle all the PC-DMIS events to know when execution is finished
              Well, that has promise... but as you could have told me (and sort of did) as soon as the Async call is made, the GUI thinks the program is over! This is going to be fun!

              Comment


              • #8
                It definitely sounds like a synchronization issue was created (or rather just made more apparent) by moving the control window commands onto the main GUI. I believe moving all of the original GUI commands into a managed background process (effectively another thread) would solve the problem. A sample use case would look like this:
                1. A button is pushed on the GUI, spawning a background process that sends the command to PC-DMIS and remains busy until the process completes;
                2. A second button is pushed on the GUI, which then checks if the background process is still busy;
                3. If the background process reports as being busy, the GUI captures the command and doesn't send it on to PC-DMIS;
                4. If the background process reports as being complete, it is started again with the new command.


                Alternatively, the GUI could disable all controls until the background process is complete, effectively eliminating the possibility of a sync issue. The Run/Hold/Stop commands would need to bypass the process check to be able to intervene with the running process in PC-DMIS. Unfortunately, I don't have much experience with having an external application intervening with an otherwise busy PC-DMIS with Run/Hold/Stop commands; most of my applications just "configure" the CMM to run by either generating a new inspection program from scratch, or telling PC-DMIS to open an existing inspection program and execute it.
                Last edited by ewe0006; 07-02-2014, 01:14 PM.
                (╯°□°)╯︵ ┻━┻

                Comment

                Related Topics

                Collapse

                Working...
                X