Jump to content
OMRON Forums

Use Rotary Buffer & update the Coordinates


Raghav
 Share

Recommended Posts

Dear All,

I'm currently using Program buffer to download my NC codes and run the machine from the GUI. But this is limited in terms of file size it can hold. I'm not sure of the exact file size that can be run using program buffer. So I tried with the rotary buffer and seems to be no issue in terms of the program, but my interrupts such as coordinates and velocity is not getting updated as the buffer is open. Even my emergency code which is placed in a PLC is not getting executed. So i have the following doubts and i would request your help to overcome the coordinate refresh which running the rotary buffer.

 

1) Will the PLC execution will be stopped while using a Rotary buffer?

2)What is the maximum file size that can be downloaded and run using a Program buffer?

3)How to overcome the periodic update of the GUI for emergency, coordinates and velocity values?

 

Thank you in advance. Looking forward for a viable solution to solve the above mentioned issues.

 

Regards,

Raghav

Link to comment
Share on other sites

  • Replies 37
  • Created
  • Last Reply

Top Posters In This Topic

You have to use binary rotary buffer. It allows a sort of "dual channel" communication, one for the ASCII requests and the other for filling the buffer.

AFAIK PLC programs are not affected when using rotary buffer.

Link to comment
Share on other sites

I test that the maximum file size that can be downloaded and run using a Program buffer is about 10,000.

And I have the same question.When I use the rotary buffer to download and run the program, I can't update the Command position which I used to sending M161.

Link to comment
Share on other sites

PLC execution will continue while motion program code runs whether it is a rotary buffer of fixed motion buffer.

 

A fixed motion buffer can be as large as available memory in PMAC. You can use the “SIZE” command to determine this.

 

Many on-line commands will be parsed by PMAC as buffered commands so it will be necessary to close the rotary buffer for these to execute and not become part of the rotary buffer program. A query for an M-variable, for example, will be parsed as an M-code.

Link to comment
Share on other sites

Turbo PMAC has a number of features using the DPRAM to pass information from/to the host computer. Each of these functions has dedicated registers in the DPRAM. See the section in the Turbo PMAC User’s manual, “DPRAM Automatic Functions”.

 

If you are not using DPRAM then you can only poll PMAC variables through the host port.

Link to comment
Share on other sites

Is there a sample program which uses Pcomm32.lib instead of Pcommserver.exe, since my application is built based on Pcomm32. I'm not able to understand the which one to use ASCII or Binary rotary and also I don't understand DPRAM Binary rotary buffer. kindly excuse me for these layman question as I'm new to this motion programming. I need to run a huge NC program and at the same time i need to update the machine status. What will be the optimal way to achieve it. Currently I'm using a Motion prog to download the program and close the motion prog buffer and then execute the motion command. But now that i need to run huge files, I'm left with RB method. But again I'm not clear on it. If i follow the Pcomm2 application as a reference and use ASCII RB and run my code, how do I check the Buffer full status in Pcomm32? How to send and close the buffer periodically? Kindly advice me on this, if possible please share any sample program for my reference.
Link to comment
Share on other sites

The installation directories of the Pcomm32 libraries package have complete example sections with code for binary rotary buffer operation. Our programming group at support@deltatau.com may be able to send further examples of code - please identify the version of the library package at that time.

 

Details on the mechanisms used in PMACs rotary buffer operation is described in the Turbo PMAC User’s manual. In general you must close the buffer temporarily to query the PMAC for other data unless you use one of the other DPRAM Automatic Functions to report status such as the following:

 

DPRAM Motor Data Reporting Buffer

======================

Turbo PMAC can provide key motor data to the DPRAM, where it can be accessed easily and quickly by

the host computer. If this function is enabled, Turbo PMAC will copy key motor registers into fixed

registers in the DPRAM. This copying function can be done either as a foreground (interrupt) task

in Turbo PMAC, or as a background task.

 

DPRAM Background Data Reporting Buffer

==========================

Turbo PMAC can provide key global and coordinate-system data as a background function to the

DPRAM, where it can be accessed easily and quickly by the host computer. If this function is enabled,

Turbo PMAC will copy key global and coordinate-system registers into fixed registers in the DPRAM.

 

 

DPRAM Background Variable Read Buffer

=========================

The Background Variable Data Read Buffer permits you to have up to 128 user-specified Turbo PMAC

registers copied into DPRAM during the background cycle.

 

DPRAM Background Variable Data Write Buffer

=============================

The Background Variable Data Write Buffer is essentially the opposite of the Background Variable Data

Read Buffer described above. It lets you write to up to 32 user-specified registers or particular bits in

registers to Turbo PMAC.

Link to comment
Share on other sites

  • 2 weeks later...

The installation directories of the Pcomm32 libraries package have complete example sections with code for binary rotary buffer operation. Our programming group at support@deltatau.com may be able to send further examples of code - please identify the version of the library package at that time.

 

Details on the mechanisms used in PMACs rotary buffer operation is described in the Turbo PMAC User’s manual. In general you must close the buffer temporarily to query the PMAC for other data unless you use one of the other DPRAM Automatic Functions to report status such as the following:

 

DPRAM Motor Data Reporting Buffer

======================

Turbo PMAC can provide key motor data to the DPRAM, where it can be accessed easily and quickly by

the host computer. If this function is enabled, Turbo PMAC will copy key motor registers into fixed

registers in the DPRAM. This copying function can be done either as a foreground (interrupt) task

in Turbo PMAC, or as a background task.

 

DPRAM Background Data Reporting Buffer

==========================

Turbo PMAC can provide key global and coordinate-system data as a background function to the

DPRAM, where it can be accessed easily and quickly by the host computer. If this function is enabled,

Turbo PMAC will copy key global and coordinate-system registers into fixed registers in the DPRAM.

 

 

DPRAM Background Variable Read Buffer

=========================

The Background Variable Data Read Buffer permits you to have up to 128 user-specified Turbo PMAC

registers copied into DPRAM during the background cycle.

 

DPRAM Background Variable Data Write Buffer

=============================

The Background Variable Data Write Buffer is essentially the opposite of the Background Variable Data

Read Buffer described above. It lets you write to up to 32 user-specified registers or particular bits in

registers to Turbo PMAC.

 

Dear Steve,

Can I have any sample DPRam based rotary buffer prog for larger NC file and real-time data gathering? Similarly the other method where we can upload a certain no. of lines and check for the buffer status and again send after a certain level is reached as shown in Pcomm example. Since I'm using Pcomm32 library, I'm not sure of how to proceed. Kindly let me know if I can get any sample programs. Thank you in advance.

Link to comment
Share on other sites

Your installation of the Pcomm32 library has many example in the example folder.

 

Dear Mr. Steve,

Thank you for your advise. I haven't used the DPRAM option. But just tried to use the "PR" command to send the command based on the buffer limit status. And I'm still testing with various file sizes and hope it would work fine. I just want to know whether it is possible to identify which line of the NC code is being executed? I tried to use the PR data for the same and found that it gives some random values since my code has more than one command (eg: G01 X0 Y10 F40). So what would be the easier way to display the executing line?

 

Thank you once again for the help.

Link to comment
Share on other sites

I use the same logic as mentioned in the PComm example but using the Pcomm32.lib option. The following are the code snippets.

 

 

OpenRotBuffer()

{

 

DeviceGetResponse(mDevice,strRes,255,"A") ;

DeviceGetResponse(mDevice,strRes,255,"&1 DEL ROT");

DeviceGetResponse(mDevice,strRes,255,"&1 DEFINE ROT 100") ;

DeviceGetResponse(mDevice,strRes,255,"DELETE TRACE DELETE GATHER") ;

DeviceGetResponse(mDevice,strRes,255,"&1 OPEN ROT CLR");

 

}

 

Step 2: Check for the PR (lesser than I16) and also "??" and get the status of the 8th digit's and status of buffer full bit. Send the G codes till the buffer is full and close the buffer and send "R" command

 

Send the G codes till the buffer is full and

 

DeviceGetResponse(mDevice,strRes,255,"CLOSE");

 

DeviceGetResponse(mDevice,strRes,255,"&1 B0 R");

 

Step 3: Currently checking the "PR" and the "??" in a timer to identify the buffer status

 

When the PR value is lesser than I16 and Buffer bit is not full, sending the codes in a while loop, till the PR value is equal to the I17

 

I open and close the buffer to send the lines

 

DeviceGetResponse(mDevice,strRes,255,"OPEN ROT");

 

Send the G codes till the buffer is full (using a WHILE loop) and

 

DeviceGetResponse(mDevice,strRes,255,"CLOSE");

 

Then again I enable my general machine timer including the PR value. Once the PR value falls below I16, I again enable the rotary timer and execute the above procedure. The program works fine until the first set of codes downloaded. But after it is executed, the program seems to be in Single step mode (found from the coordinate status tab in PEwinpro) and the motion is intermittent. How do I overcome this issue? I need to finish this code execution by today. Can anyone suggest me where I'm going wrong and what should I add or modify to achieve rotary buffer program with the machine status update as well. Your reply is much appreciated and looking forward for your valuable input.

 

Regards,

Raghav

Link to comment
Share on other sites

You can use the “PR” command to determine when the rotary buffer is too low or poll the “Rotary Buffer Request Bit” with the “??” command. This does not require the rotary buffer to be closed as these are purely on-line commands. Usually just one technique is used for the on-going maintenance of the buffer although the “PR” command can be useful when using the latter technique to help determine if the I16/I17 settings are sufficient.

 

Note that when using the “PR” command only, I16 and I17 are not needed as you are directly determining the number of lines left in the buffer.

 

These I-variables are use when polling the “Rotary Buffer Request Bit”. Since there are three words to decode it may be easier to poll a single bit M-variable definition to this bit. When doing this you are required to close the rotary buffer, as a query for this M-variable value would be buffered as an M-code into the rotary buffer.

 

The effects you see are probably a result of the rotary buffer running out of lines and coming to a stop. Note that if PMAC executes the lines too quickly or the PC is slow in reacting to a low buffer state this can happen. If PMAC is in segmentation mode (I13>0) and is executing the last line in the rotary buffer, as long as a new line is entered before the start of deceleration to stop, PMAC will blend into the new move without stopping.

Link to comment
Share on other sites

You can use the “PR” command to determine when the rotary buffer is too low or poll the “Rotary Buffer Request Bit” with the “??” command. This does not require the rotary buffer to be closed as these are purely on-line commands. Usually just one technique is used for the on-going maintenance of the buffer although the “PR” command can be useful when using the latter technique to help determine if the I16/I17 settings are sufficient.

 

Note that when using the “PR” command only, I16 and I17 are not needed as you are directly determining the number of lines left in the buffer.

 

These I-variables are use when polling the “Rotary Buffer Request Bit”. Since there are three words to decode it may be easier to poll a single bit M-variable definition to this bit. When doing this you are required to close the rotary buffer, as a query for this M-variable value would be buffered as an M-code into the rotary buffer.

 

The effects you see are probably a result of the rotary buffer running out of lines and coming to a stop. Note that if PMAC executes the lines too quickly or the PC is slow in reacting to a low buffer state this can happen. If PMAC is in segmentation mode (I13>0) and is executing the last line in the rotary buffer, as long as a new line is entered before the start of deceleration to stop, PMAC will blend into the new move without stopping.

 

Dear Mr. Steve,

I used the ?? and found the 8th word's binary to identify the buffer status. I send 1000 lines initially and just after every word, I poll for ?? to get the buffer bit status. After the 1000 lines are sent or if the buffer becomes full, I stop sending the commands. Again I send the lines when the buffer is not full and query in the similar way as before.

 

I face these conditions:

 

1)When I run a code sequence of X0.05F50, Y0.5F30, X0Y0F30 for about >300 times, it executes them properly since there is enough time to execute each line.

 

2)When I run a code of a rotary axis with a particular feedrate, say 10rpm (F3600), it works fine at times and at times the rotary axis rotates intermittently. With the same code, when I try to run the axis with a feedrate of 7200, it starts to rotate intermittently from the starting move itself. Both the codes are same with just one single axis commanded. So I have 1440 lines and since only one single command is there I assume the the lines to be executed in PMAC is also 1440. Rot buffer size is 1000 and I16 & 17 are 300& 600 resp. So I'm not sure of why this situation happens. I tried with both FRAX and NOFRAX command as well. Result is same. Also I tried to change from Seg. mode to Non-seg. mode (Isx13 5 to 0 & Isx20 to 0) and I found the F set for axis changes. Since it's a rotary axis I find difficulty in finding the exact feed rate at which the axis is rotating.

 

3)When I run a code with just "PR" check, it work fine and better than "BIT Req" method, but still at the end of the code, it starts to move intermittently. I see the PR value falls below 10 as well. But from the programming side, I have the same logic, but check for the PR command only after the certain no. of lines are sent to PMAC. Similar to previous case, when the feedrate increases, the motion is intermittent.

 

With all the methods and FRAX in place FRAX(X,Y,C), still couldn't achieve the proper motion.

 

To check with the coding load, i used a application in which I just send the lines using directly the PMACgetresponse(......) call. It also yielded the same result, better for lower feedrate (3600) rotates fine until near end, and only starts to intermittent motion at the end. With higher feedrate(7200) I don't achieve the necessary continuous motion.

 

Also to check from the PMAC side, we tried to use the Turbo 2 PMAC with 160MHz processor since the one which we use is 80MHz. The same "PR" based code with direct PMAC calls worked fine in the other machine with 160MHz processor. I haven't compared the parameters, but one thing which I noticed is that, the machine with 160MHz CPU didn't have any motion or PLC program in it. But in my machine, I have the standard motion programs and a couple of PLCs. Will it be an issue? Also in my GUI, I call the PMAC function using a PMAC class object. Will it be an issue?

 

I'm sorry have too many things in the post. But seriously I'm struck with this issue for the past one week and I'm in such a urgency to finish off this project. Hope you could let me know a solution which i could use immediately to solve this issue. If I need to change the hardware (CPU) too, I can do it immediately.

 

Thank you once again for your support and hope you could help me in solving this issue.

Link to comment
Share on other sites

  • 2 weeks later...

Dear Steve,

I had solved the issue. It was the computer data transfer issue. I changed the computer and now the issue is resolved for a particular mode. When I don't use the SPLINE command, and use FRAX instead the execution is proper. Also when I change the Isx13>0 (curently 5) and the Isx20=4, it works fine, but when I make Isx13=0, it lags. So what could be the cause of this issue? And if I need to use Isx13 and SPLINE mode, what changes do I need to make? Also is my Isx20 value correct? Can I understand the use of Isx13 and Isx20?

Link to comment
Share on other sites

  • 3 months later...

Dear Mr. Steve,

I still face the same issue with the Rotary buffer. My initial problem of sporadic motion of the axis is due to two reasons: 1) The PC which we were using to send the command was slow to the extent that the no. of lines sent to PMAC was negligible compared to the motion. 2) The motion path was so small that the axes reached the position sooner and hence every line is executed faster than the lines being sent.

 

Now I solved the prior issue by changing the PC and some tweaks in the coding as well. Everything works fine except one which is the real-time update.

 

I had added the M999==1,2,3 etc and it works pretty well with smaller no. of NC lines. The user is updated with the executing line and also the real-time co-ordinates are updated. Now coming to the larger NC files, I'm sending them based on the PR value and it works fine if I don't close the buffer in-between for the querying of executing line and also the co-ordinate's values. But the NC lines downloaded till the first closing of the rotary buffer works fine, but the prog/machine hangs after that. No other NC lines are executed after that.

 

So how do I go about it? Is the closing and opening of Rotary buffer allowed? What will be the best way to update the user with the executing line and co-ordinates? If I need to use the DPRam, what is the procedure to go about and will it involve to many changes in the coding aspect.

 

Sorry for too many questions, but I don't find a work around to solve this rotary buffer issue.

 

Thank you in advance for your valuable support.

Link to comment
Share on other sites

What program is hanging your host program or the PMAC program?

 

Can you show the coding sequence you have for open/close of the rotary buffer?

 

Main Function:

 

PMACCom("PR");

PR = atoi(strRes);

 

if(PR<750)

{

for (int i =0; i<=(1500-PR); i++)

{

command = "M999==" + AnsiString(LineIndex+1);

PMACCom(command.c_str());

if(total_line_count<5000)

PMACCom(code_str[LineIndex].c_str());

else

PMACCom(String[LineIndex].c_str());

command = "";

LineIndex++;

if(LineIndex>=(total_line_count))

{

if(firstRUN ==true)

{

PMACCom("&1B0R");

firstRUN = false;

}

PMACCom("CLOSE");

tmrUpdateMachineState->Enabled = true;

return;

}

}

if(firstRUN ==true)

{

PMACCom("&1B0R");

PMACCom("CLOSE");

firstRUN = false;

sub_function();

}

}

 

Call this sub-function:

 

if(LineIndex

{

AnsiString command ;

 

PMACCom("PR");

int PR = atoi(strRes);

 

if(PR<750)

{

tmrUpdateMachineState->Enabled = false;

PMACCom("&1 OPEN ROT");

 

for (int i =0; i<=(1500-PR); i++)

{

command = "M999==" + AnsiString(LineIndex+1);

PMACCom(command.c_str());

if(total_line_count<5000)

PMACCom(code_str[LineIndex].c_str());

else

PMACCom(String[LineIndex].c_str());

command = "";

 

LineIndex++;

if(LineIndex>=(total_line_count))

{

PMACCom("CLOSE");

tmrUpdateMachineState->Enabled = true;

return;

}

}

}

else

{

PMACCom("CLOSE");

tmrUpdateMachineState->Enabled = true;

 

}

}

else

{

PMACCom("CLOSE");

tmrUpdateMachineState->Enabled = true;

return;

}

 

So I call this subfunction from my machine update timer every 50 ms. The problem I face is when I use the "CLOSE" command in the subfunction and again try to open in the subsequent call. But if I dont close and just check for the buffer limit and send the code, the motion is normal without any issue.

 

Kindly suggest me where i'm committing a mistake.

Link to comment
Share on other sites

It is difficult to tell from the code fragment if you may be missing the "open". Or it could be timing.

 

does it fail on the first "open" or later ones?

 

It is able to execute 600 lines everytime and stops. PR value shows 1200 after the program stops. So it stops at the after the first close. The subsequent open is not working.

Link to comment
Share on other sites

Does the PMAC continue to execute motion lines?

 

How does you program open the buffer at the beginning of the "for" loop?

 

No, The program stops exactly after executing 600 lines. But the lines are sent to the rotary buffer which is 1200 provided by PR command once after the motion is stopped. Also the GUI get back to the update thread since the PR value is more than 750.

 

The first rotary open is as follows

 

PMACCom("A");

PMACCom("&1");

PMACCom("Q CLOSE I9=0");

PMACCom("&1 DEL ROT");

PMACCom("CLS");

PMACCom("CLR");

sprintf( strCom, "&1 DEFINE ROT %d",BufferSize);

PMACCom(strCom);

PMACCom("DELETE TRACE");

PMACCom("DELETE GATHER");

PMACCom("&1 DEFINE LOOKAHEAD 1000,500");

PMACCom("&1B0");

PMACCom("&1 OPEN ROT CLR");

 

And the subsequent open is as in the code snippet provided.

 

The code execution is fine, if I don't close the buffer until all the NC codes are sent to the buffer. Hope you could provide a solution for this problem since we are struggling with it for long time now.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share


×
×
  • Create New...