We are looking to implement the OMA/VCA compliant protocol to a laser engraving/marking software application. The software needs to communicate on a TCP/IP network. The data communications standard used by most lab equipment was developed by a group working under the auspices of the OMA. The ISO version of the standard is intended to be identical, but because the highly-formalized ISO process is slower than the more ad hoc VCA process, the ISO version is usually one version behind the VCA's. We encourage everyone to work from the current VCA version. Here is the definition of the standard: The Optical Manufacturer's Association ("OMA") became the Optical Industry Association (strangely, still "OMA") which became the Vision Council of America ("VCA"). Here is the background history on the DCS (Data Communication Standard). Maybe this will help explain this protocol and communication standard.
1. In the old days.....nearly all of the lab equipment communicated on some form of serial port, either RS-232 or even RS-422. As such, the first priority of the DCS was to keep the packets small for speed of transmission. Hence the situation where the DCS maybe has 200 possible data labels, but any single machine might only need five. Through the "auto-initialization" exchange, the machine and host computer would agree on those five, and proceed from there.
2. When lab "digital" processing began, it was quickly realized that the HIGHLY detailed back surface and 3D lens surface data files were too large to transmit via RS-232. Therefore the decision to utilize "shared" folders came about. Now two (2) communication cables had to be run, one serial, one Ethernet. In the job packet, we/host computer, sends "LDPATH=" which gives the directory path (i.e. [login to view URL], [login to view URL] or [login to view URL]) and filename of that 3d lens surface data table which the machine then pulls without any "delivery" on our part. I repeat, the shared folder usage is ONLY for this file. If your machine doesn't need it, then only RS-232 is needed.
3. Thinking "outside" the box...if you can't/don't want to write an RS-232 serial interface, you could use the "shared" folder idea, forget the auto-initialization phase, and just grab our entire DCS file in the ./oma,dir You would then just pull out of that file the labels you need. Caution - there is one disadvantage to this. If you were to do that, the order server HOST wouldn't "know" you pulled it. We have a module in our system called "Tray Tracking". When a blocker requests tray 12345, we updated Tray Track. When the generator requests tray 12345, save that. Then Customer Service knows approximately where the tray is in the lab. If you just pull the complete file, we wouldn't be able to save that level of detail.
4. We have developed a "socket" based Ethernet exchange of auto-initialization and job packets. Attached is the VCA standard. Everything is in there to create a compliant network application. Check page 66 for the "Auto-Initialization" examples.