Leo Posted July 4, 2017 Posted July 4, 2017 I met a problem when using DPRAM binary rotary buffer on clipper. It seems that the DPR binary rotary buffer didn't copy all of the NC codes to internal rotary buffer. The machine didn't stop at the last program line. I checked the internal buffer with "list rot" command and found the last few program lines wasn't there. The machine didn't stop at a static position even I downloaded the same NC file again. The same thing happened on POWER NC software when using turbo controller. I think there's something need be noticed with DPR binary rotary buffer. But what's that ?
Omron Forums Support Posted July 5, 2017 Posted July 5, 2017 How old is your Turbo Clipper? We had an issue many years ago which was caused by corrupt communications software. Simply reloading the communications software would fix the issue. If your Clipper is old this could be the issue. If your Clipper is relatively new this will not be the issue. If you run a particular NC file, will it stop at the exact same location every time? If your run a different NC file, will it also stop at the exact same location every time but on a different line than the above file?
Leo Posted July 6, 2017 Author Posted July 6, 2017 How old is your Turbo Clipper? We had an issue many years ago which was caused by corrupt communications software. Simply reloading the communications software would fix the issue. If your Clipper is old this could be the issue. If your Clipper is relatively new this will not be the issue. If you run a particular NC file, will it stop at the exact same location every time? If your run a different NC file, will it also stop at the exact same location every time but on a different line than the above file? The motion program may stop at the last few lines but not a static line number. I tried 3 Clipper boards and there's a relatively new one. All of them got the same result. I tried 10 different NC files and the problem is still there. Every thing is ok except the lower communictaion speed if I use internal rotary buffer. Power NC software with rotary mode has the uncomplete sending problem also. I think it's the business of binary rotary buffer . Is there any paticular setting of it? I set the headers as follow: DPRBINROT Initial: M71->X:$60414,24 ; (X:$60414) CS enable M72->Y:$60415,24 ; (Y:$60415) host binary rotary index M73->X:$60415,24 ; (X:$60415) pmac binary rotary index M74->Y:$60416,24 ; (Y:$60416) Size of binary rotary buffer M75->X:$60416,24 ;(x:$60416) starting binary address offset M71=1 M72=0 M73=0 M74=1024 M75=0 &1 define rot 1024
Unit101 Posted July 12, 2017 Posted July 12, 2017 I suspect your problem is that you are not filling the Ethernet packet at the end so it is NOT sent until full. I assume your HMI is using pcomm and the DPRAsciiStrToRotEx function call - when sending last line in buffer you must set the bufSendImmediate to TRUE - this way it will send the last few lines EVEN if not fill up the packet... - otherwise it should be set to False, so it fills a packet then sends a group of lines --- here is code snippet from my example dpram application.... //if this is the LAST line to send we need to flush the comm buffer //OR if we are in SingleStep mode we have to send each line as it comes if (curLineSend == totalNcLineCnt || SingleStepCheckBox.Checked) { bufSendImmediate = true; } Pmac.DPRAsciiStrToRotEx(m_nDevice, command, 0, bufSendImmediate, out status);
Omron Forums Support Posted July 12, 2017 Posted July 12, 2017 I sent you a personal email with instructions. Did you receive? If not check your account settings to be sure your email listed is correct.
Leo Posted July 12, 2017 Author Posted July 12, 2017 Unit101, Yes,you are right. The last line must be sent in immediate mode. I followed your guide and the problem disappeared. Thank you.
Leo Posted July 12, 2017 Author Posted July 12, 2017 I sent you a personal email with instructions. Did you receive? If not check your account settings to be sure your email listed is correct. I got it . Thank you very much.
Recommended Posts