Jump to content
OMRON Forums

DPR binary rotary buffer problem


Leo

Recommended Posts

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 ?

Link to comment
Share on other sites

  • Replies 6
  • Created
  • Last Reply

Top Posters In This Topic

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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);

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...