Is it a bug of IGES reading a long string in head segment.

Hi All,

I find a strange iges file. I read it in other three CAD/CAE softwares, and find the model sizes are all about 270. But I read it in my software using OCC, the model size is about 6000. Yes, most of these problems are caused by different unit reading. But I find it's not in this case. I debug it and find a potential (maybe it's not a bug, :)) bug in void iges_param(Pstat,ligne,c_separ,c_fin,lonlin)
, this function is in analiges.c file.

void iges_param(Pstat,ligne,c_separ,c_fin,lonlin)
int *Pstat; char c_separ,c_fin, *ligne; int lonlin;
{
int i,i0,j; char param[80]; char unpar;
if (*Pstat == 0) reste = 0;
if (*Pstat != 2) numcar = 0;
if (*Pstat else {
numcar = nbcarH;
if (numcar > lonlin) {
iges_addparam(lonlin,ligne);
nbcarH -= lonlin; /* ??? enregistrer ... ??? */
return;
} else {
iges_addparam(nbcarH,ligne);
nbcarH = 0;
/*******Start: I add a line here to try to fix the potential bug*************/
reste = 0;
/*******End: I add a line here to try to fix the potential bug*************/
}
}

I attached a iges head file, you can copy these contents and replace head contents in your iges file. And compare it with your raw iges file. You will find the model will have two different sizes.

PS: The system ID segment is a long string and crosses two lines. The occ treats this head file as scale = 2.0, unit=null.

Thanks in advance.
Ding

Attachments: 
Andrey Betenev's picture

Hello,

The reason of the problem is inconsistent IGES header: missing comma after string identifying generating system (between "INC." and "6H980406"). The comma is declared as field separator in the first field of the global section (and it is also default separator), and it must be used to separate fields. Lack of comma causes fields to be incorrectly enumerated, and the result is incorrect unit interpreted by OCCT IGES translator.

Another problem is that in the date field you have ** instead of numbers indicating the year. It looks as if this file was generated by quite old system, not even protected against "2000 year" problem.

Thus primary means to avoid the problem is to fix IGES file.

Nevertheless, it might be reasonable to improve OCCT IGES reader to be able to treat such cases more robustly (probably the correction you suggested will do the job). I have recorded this case in OCCT bugtracker for further treatment (id OCC21994). Please keep track of OCCT release notes to know if it is resolved.

Andrey

Cauchy Ding's picture

Hi, Andrey

I am really appreciated for your so quick answer and so detailed explaination.
Yes, I know the head lost one "," after "INC.". But even I add "," to "INC.", occ still can't analysis this head correctly.
Thanks.

Ding

Andrey Betenev's picture

Hello Ding,

Please double-check (with non-modified version of OCCT); putting comma after "ÏNC." should help. I have checked this by replacing header in the file bearing.iges that comes with OCCT distribution by your variant. Putting comma (instead of space) fixes the problem of units in both OCCT 6.3.0 and 6.3.1.

Andrey

Cauchy Ding's picture

Hi Andrey,
Yes, you are right. If I only add a comma to "INC.", it doesn't work. But if I replace the space after "INC." with comma, it works. However, would you please give me some suggestion on how to fix this "bug" head which generated from other CAD/CAE systems?
Thanks in advance.

Ding