data transmission error

[LuisVito]

Hello everyone!
I have a problem with my work center, kafo model and fanuc control 0m.
It is already the second time that while I'm working a mold the machine performs paths not present in the program, causing damage to the mold, this happens while performing 3d jobs.

Can it be a transmission error? the machine is of 1995 to transmit the data use the rs232 port and the transmission program is cymco.

 

[flfn]

Hi, it's a strange thing, I ask you the following questions:
- transmision and dnc;
Did you simulate the program with the cymco or fanuc simulator to control it? ?

greetings
♪

 

[Meccbell]

when you have errors in the transmission usually it can also happen that the machine performs wrong movements compared to the program, but usually one of the first things, if not the only, that happens is that the alarms due to incorrect syntax of the machine blocks (e.g. a coordinate with 2 attached quotas, type x45.583.10, due to the lack of the letter relative to the second axis, which has lost ".

in good substance, it can also happen that there are one or more movements that generate "dissasters", but usually immediately after the machine goes into alarm and stops.
and this, if you repeat, should happen so "random" so never in the same program line.
if this is the scenario, then the problem is in data transmission, for causes that can be: poor quality of cablings (electric interference), set-ups "at the limit" of transmission software parameters or of the same PC or machine cards (e.g., too high baudrate or transmission/reception buffer too large), or even problems due to the use of a pc on which they live too many programs along with the dnc system, perhaps even with someone who uses, even if only temporarily, the same resources of memory, with the result that every so much

if instead the machine continues "imperterrita" to work after doing what it did not have to, perhaps recovering the working in the right way, as if nothing were, then in 99% of the cases, and above all, contrary to the case above, if the problem always happens at the same point of the program, then the error is due to something that did not work on the cam level, perhaps for wrong movements generated by errors on the surfaces of the mathematical model of the bad
In this case I share the advice to carefully verify the simulation of the processing, perhaps proceeding step by step and, if the cam allows it, controlling with equal care the list generated by the postprocessor as the program flows.