Previous | Next | DMIS
Topic: Feature Definitions, why only one?
Conf: DMIS, Msg: 277
From: Deleted User
Date: 7/27/1998 01:03 PM

Keith,
I do realize that LK-DMIS will allow repetitive feature definitions. The problem with this is that some DMIS interpreters follow the standard more strictly and do not allow this. So, when you take a program of this nature to a different CMM, it wont run. Thus, where is the standard that is designed to allow a common language across all CMM platforms? It's not just LK, all the DMIS based CMM software that I have seen have these little non-standard kickers. The key is just to not use them.

As for the 'Vender' specific commands. The idea of putting these commands behind the '$$' is simple. Lets use your LOCATE command as an example. This command is not standard, so therefore will not run on another DMIS interpreter that I'm currently beta testing. If it were required that commands of this nature were put behind the '$$' it would not flag a syntax error with other vendors software. Now, each vendors interpreters would have to be designed to not only recognize '$$' as a comment and not an executable command, but would also have to scan the contents of the comment line to see if there 'is' a vendor specific command that does need to be executed. I know what your thinking right now, 'If the LOCATE command were being used on an LK, and then ran on a different CMM and was not executed, then the alignment would not happen, thus making the program no good to begin with', welp I'm just using this command as an example. I hope your getting the gist of what I'm trying to say though. I feel this type of functionality would give the vendors an avenue to jazz up there software with commands that could set them apart from there competitors, while still allowing them the freedom to say they are 'Pure DMIS' compatible. what's your thought on this?

Please don't get the idea that I'm doing way to much complaining, but I guess you can say that I am. :) We looked long and hard at DMIS before we decided to go with it, due in part to the direction that Chrysler may chose for future CMM programming platforms. Now that we have started the move in that direction, I will push very hard to keep systems compatible across multiple CMM brands that we use and may use in the future. I have also contacted members of Chrysler who represent us at the DMIS Users group and DNSC, so I'm not just complaining, I'm getting the complaints out to those who will listen. I have been invited to be a representative for Chrysler, but that is still up in the air and will be decided by my plants willingness to pay for the expense of such an activity...
Keep in touch...

John Foreman
Chrysler, Kokomo Casting Plant