Trying to connect Huvitz AutoBlocker CAB4000 with data transmission OMA protocol

Printable View

07-04-2019, 12:36 PM
c.menghi

Trying to connect Huvitz AutoBlocker CAB4000 with data transmission OMA protocol

Hi, I'm trying to connect my tracer+edger to transmit shapes to my lens provider; I get to the point to have data received on my PC but trasmission never result in a shape, althought the app say the for is correctly received and trasnmitted, here is some sample data:

Code:

DO=B ANS=TRC JOB=METAL:0002869 DATA_TYPE=19 FTYPE=3 P_FPD=6916 LAYOUT=17.928;0;5.000;5.000;25.000;0;0 P_R_CIR=146301 P_R_3D_ANGLE=0 P_R_FC=5684 R_LOPT=30.200;0.000 R_EOPT=1;0;1;0;0;1;1;1.200;0.000;0.400;0.600 P_L_CIR=146272 P_L_3D_ANGLE=0 P_L_FC=5630 L_LOPT=30.200;0.000 L_EOPT=1;0;1;0;0;1;1;1.200;0.000;0.400;0.600 TRCFMT=5;1440;U;R;F TRCFMT=5;1440;U;R;F CRC=26173
07-10-2019, 04:30 PM
MakeOptics

Quote:

Originally Posted by c.menghi

Hi, I'm trying to connect my tracer+edger to transmit shapes to my lens provider; I get to the point to have data received on my PC but trasmission never result in a shape, althought the app say the for is correctly received and trasnmitted, here is some sample data:

Code:

DO=B ANS=TRC JOB=METAL:0002869 DATA_TYPE=19 FTYPE=3 P_FPD=6916 LAYOUT=17.928;0;5.000;5.000;25.000;0;0 P_R_CIR=146301 P_R_3D_ANGLE=0 P_R_FC=5684 R_LOPT=30.200;0.000 R_EOPT=1;0;1;0;0;1;1;1.200;0.000;0.400;0.600 P_L_CIR=146272 P_L_3D_ANGLE=0 P_L_FC=5630 L_LOPT=30.200;0.000 L_EOPT=1;0;1;0;0;1;1;1.200;0.000;0.400;0.600 TRCFMT=5;1440;U;R;F TRCFMT=5;1440;U;R;F CRC=26173

DO record indicates that both lenses will be supplied and the record apply to both
ANS record indicates it's an answer packet from the TRC tracer
JOB record is the job number in this case they are using a colon in the job id with METAL I assume to mean a metal frame as the first data point and the 0002869 as the job number this is not conventional.

The Standard allows for device manufacturers to create new records for additional functionality and possibly even submission for approval in the new standard by indicated the an experimental record, which should start with an "_", in the case the underscore is in the middle of the label so again this is non-conventional.

DATA_TYPE ?
FTYPE record indicates I am assuming this is an equivalent of FTYP notice the E is missing, this again is unconventional to add letters to the record label but I assume they mean the same, FTYP indicates the frame type a 3 means the frame is a rimless frame.
P_FPD (unconventional) I am assuming this is the far pupillary distance which should have used the IPD record
LAYOUT (unconventional) it looks like the layout record is combining multiple records into a compact record, could be horizontal decentration, vertical decentration, height, width, etc.

I could go on and on, anyway the records there mostly make sense, you may need to run a separate conversion program to take the huvitz trace files an convert them to proper OMA files. I had the pleasure of doing this to the Santinelli trace files which were 99% OMA compliant with some artifacts left over from experimental records that had been approved.

A side not the TRCFMT=5;1440;U;R;F, the 5 is reserved for future formats, as far as I know a more compact format that could possibly take the 5 format doesn't exist yet except maybe by the huvitz, then the U later indicates that the trace radii supplied is unequal meaning the 1440 trace points around the lens are not equally taken so a corresponding angle record must be there to be able to do anything with this trace.

I am assuming the EOPT records are probably the radius data in their particular format.

If you have more samples like a lot more I used a statistical analysis program to identify the records and correlate them to a few know records or parameters from traces which helped decipher the santinelli version.
07-12-2019, 10:29 AM
c.menghi

Quote:

Originally Posted by MakeOptics

If you have more samples like a lot more I used a statistical analysis program to identify the records and correlate them to a few know records or parameters from traces which helped decipher the santinelli version.

This is the full output:

https://pastebin.com/ScdAhrJE
07-12-2019, 11:11 AM
c.menghi

Quote:

Originally Posted by MakeOptics

DO record indicates that both lenses will be supplied and the record apply to both
ANS record indicates it's an answer packet from the TRC tracer
JOB record is the job number in this case they are using a colon in the job id with METAL I assume to mean a metal frame as the first data point and the 0002869 as the job number this is not conventional.

The Standard allows for device manufacturers to create new records for additional functionality and possibly even submission for approval in the new standard by indicated the an experimental record, which should start with an "_", in the case the underscore is in the middle of the label so again this is non-conventional.

DATA_TYPE ?
FTYPE record indicates I am assuming this is an equivalent of FTYP notice the E is missing, this again is unconventional to add letters to the record label but I assume they mean the same, FTYP indicates the frame type a 3 means the frame is a rimless frame.
P_FPD (unconventional) I am assuming this is the far pupillary distance which should have used the IPD record
LAYOUT (unconventional) it looks like the layout record is combining multiple records into a compact record, could be horizontal decentration, vertical decentration, height, width, etc.

I could go on and on, anyway the records there mostly make sense, you may need to run a separate conversion program to take the huvitz trace files an convert them to proper OMA files. I had the pleasure of doing this to the Santinelli trace files which were 99% OMA compliant with some artifacts left over from experimental records that had been approved.

A side not the TRCFMT=5;1440;U;R;F, the 5 is reserved for future formats, as far as I know a more compact format that could possibly take the 5 format doesn't exist yet except maybe by the huvitz, then the U later indicates that the trace radii supplied is unequal meaning the 1440 trace points around the lens are not equally taken so a corresponding angle record must be there to be able to do anything with this trace.

I am assuming the EOPT records are probably the radius data in their particular format.

If you have more samples like a lot more I used a statistical analysis program to identify the records and correlate them to a few know records or parameters from traces which helped decipher the santinelli version.

I could go on and on, anyway the records there mostly make sense, you may need to run a separate conversion program to take the huvitz trace files an convert them to proper OMA files. I had the pleasure of doing this to the Santinelli trace files which were 99% OMA compliant with some artifacts left over from experimental records that had been approved.

Which is the program i can use to convert Huvitz trace file to Oma?
07-12-2019, 01:33 PM
MakeOptics

Sorry I should have been clear you need to create the program for conversion. It looks like the full paste in you posted has everything it needs and understandable as well. I'll take a better look tonight when I get home. The format definitely needs to be converted from a 5, but there's no information about what a 5 format is, it looks like a simple diff, the first radius is an absolute and the following are diffs. I'll see if I can create an image for you to take a look at and confirm the shape if it's correct then you now know how to decode and encode a huvitz format 5.

Something you could do to make conversion easier is to then set the edger to a specific format, if I remember correctly huvitz edgers allow you to set the maximum format, for simplicity I would say set it to format 1 which will take longer to transmit but give you exact radius and angles without having to unpack the numbers.
07-14-2019, 02:45 PM
c.menghi

Hi Make Optics, in my Autoblocker i have the following Data Format: ASCII Absolute, Binary Absolute, Binary Differential, Packed Binary and Data Points: 1440, 1200, 1000, 800, 500. Which is the correct combination? Thank you for your help.
10-28-2019, 05:14 AM
c.menghi

Hi, probably i have to upgrade the firmware or software of my Huvitz Autoblocker Cab 4000 because it has at about 6/7 years, but it is not sure that the machine works correctly and i can transmit in the right mode the OMA tracer files. Anyone can help me?
Thank Yout.
10-29-2019, 12:39 PM
MakeOptics

Quote:

Originally Posted by c.menghi

Hi Make Optics, in my Autoblocker i have the following Data Format: ASCII Absolute, Binary Absolute, Binary Differential, Packed Binary and Data Points: 1440, 1200, 1000, 800, 500. Which is the correct combination? Thank you for your help.

If you want human readable pick ASCII Absolte, Binary Absolute is also easier to work with and it transmits faster, Packed Binary require a bit more work and conversion but transmits even faster than the previous 2. If you are planing on saving and working with the data 1 or 2 are your best options. 1440 or 1200 point are best, better resolution for the shape, you can always down sample the data but trying to up sample the points require inference which I personally would rather avoid.
11-05-2019, 05:23 AM
c.menghi

In my tracer menu, there is not OMA Protocol but DCS Protocol; is it the same thing or not? I attach some images of my Autoblocker menu, thank you for you help.

Gallery: https://postimg.cc/gallery/323bs3z6q/

https://i.postimg.cc/sQ2yWgs8/20190720-095654.jpg https://i.postimg.cc/3y1YWv5m/20190720-095702.jpg https://i.postimg.cc/CZSwF4tw/20190720-095724.jpg https://i.postimg.cc/VJjYQhK7/20190720-095730.jpg

https://i.postimg.cc/zymJQNFb/20190720-095737.jpg https://i.postimg.cc/dDxQ8r79/20190720-095744.jpg https://i.postimg.cc/grJkXN0J/20190720-095749.jpg https://i.postimg.cc/9wrW6FkT/20190720-095757.jpg
11-11-2019, 12:47 PM
MakeOptics

Yes DCS stands for the OMA Data Commucations Standard.
11-13-2019, 06:48 AM
shanbaum

I've looked at the data and it is hopelessly non-standard. First of all, there is no "format 5" - they've obviously created their own text-based version of something like the differential format. Second, they're using some standard records (e.g., "JOB") in a nonstandard manner. They can do what they want when communicating among their own devices and software, but this variant of the standard is not going to work with anything else.

"DCS" (Data Communication Standard) is the same as "OMA" (Optical Manufacturers Association, the name of the Vision Council when the standard was initially produced). I would expect any of the four formats (ASCII through Packed Binary) to work, depending on the receiving software, but I don't know how the device is set to do its own, very strange, variant (which you need to turn off). I'd stay as far away from that as possible.