Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Use Rotary Buffer & update the Coordinates
#1
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
Reply
#2
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.
Reply
#3
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.
Reply
#4
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.
Reply
#5
Is there any method to gather he Command position whithout query for an M-variable?
Reply
#6
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.
Reply
#7
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.
Reply
#8
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.
Reply
#9
(07-15-2013, 02:05 PM)steve.milici Wrote: 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.
Reply
#10
Your installation of the Pcomm32 library has many example in the example folder.
Reply
#11
(07-25-2013, 05:35 PM)steve.milici Wrote: 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.
Reply
#12
Use a synchronous M-variable on each line of your motion program to indicate the line number.
N10 X10 M99==10
N20 X20 M99==20
N30 X30 M99==30
N40 X40 M99==40
Then monitor the M-variable in your application.
Reply
#13
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
Reply
#14
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.
Reply
#15
(07-30-2013, 10:58 AM)steve.milici Wrote: 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.
Reply
#16
I think you are now describing a different problem than keeping the rotary buffer full. Your issue may be a motion/trajectory problem. Can you send me your motion code in full?
Reply
#17
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?
Reply
#18
Lookahead requires Isx13 to be greater than zero. Take a look at the this section of the TURBO PMAC USER MANUAL, "Turbo PMAC Lookahead Function" starting on page 307 (323 PDF).
Reply
#19
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.
Reply
#20
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?
Reply
#21
(11-25-2013, 04:28 PM)steve.milici Wrote: 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.
Reply
#22
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?
Reply
#23
(11-26-2013, 04:39 PM)steve.milici Wrote: 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.
Reply
#24
Does the PMAC continue to execute motion lines?

How does you program open the buffer at the beginning of the "for" loop?
Reply
#25
(11-27-2013, 03:26 PM)steve.milici Wrote: 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.
Reply
#26
(11-28-2013, 06:31 AM)Raghav Wrote:
(11-27-2013, 03:26 PM)steve.milici Wrote: 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.

In your code:

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

//******************************************************

I would comment out the PMACCom("CLOSE"); and see what happend.
I´m almost sure it will make it.

This code:
if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");

->will stop execution before it is finish.

Instead of sending "CLOSE" ,send a M30 and make a CMD"CLOSE" inside the M30, but first try the
comment out of the PMACCom("CLOSE"); and test it.

//**********************************************
To find out pmac need more lines I use to read this address
ry:$203f
Read bit 17 :
pmac need more lines if (readresult and 65536)=0

I only use the PR command for fun to display a progressbar.
Reply
#27
(11-29-2013, 01:15 AM)JBauer Wrote:
(11-28-2013, 06:31 AM)Raghav Wrote:
(11-27-2013, 03:26 PM)steve.milici Wrote: 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.

In your code:

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

//******************************************************

I would comment out the PMACCom("CLOSE"); and see what happened.
I´m almost sure it will make it.

This code:
if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");

->will stop execution before it is finish.

Instead of sending "CLOSE" ,send a M30 and make a CMD"CLOSE" inside the M30, but first try the
comment out of the PMACCom("CLOSE"); and test it.

//**********************************************
To find out pmac need more lines I use to read this address
ry:$203f
Read bit 17 :
pmac need more lines if (readresult and 65536)=0

I only use the PR command for fun to display a progressbar.

The CLOSE after

if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");

and the last close after the last else is to close the buffer once all the NC codes are sent to PMAC. So I had commented the 2nd "CLOSE" and just enabled the machine timer.

I tried with commenting the "Close" command. But there is memory violation errors popping out. I hope since the buffer is open and i try to update the machine status, PMAC creates an error since the UI queries the M variables.
Reply
#28
(11-29-2013, 01:43 AM)Raghav Wrote:
(11-29-2013, 01:15 AM)JBauer Wrote:
(11-28-2013, 06:31 AM)Raghav Wrote:
(11-27-2013, 03:26 PM)steve.milici Wrote: 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.

In your code:

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

//******************************************************

I would comment out the PMACCom("CLOSE"); and see what happened.
I´m almost sure it will make it.

This code:
if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");

->will stop execution before it is finish.

Instead of sending "CLOSE" ,send a M30 and make a CMD"CLOSE" inside the M30, but first try the
comment out of the PMACCom("CLOSE"); and test it.

//**********************************************
To find out pmac need more lines I use to read this address
ry:$203f
Read bit 17 :
pmac need more lines if (readresult and 65536)=0

I only use the PR command for fun to display a progressbar.

The CLOSE after

if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");

and the last close after the last else is to close the buffer once all the NC codes are sent to PMAC. So I had commented the 2nd "CLOSE" and just enabled the machine timer.

I tried with commenting the "Close" command. But there is memory violation errors popping out. I hope since the buffer is open and i try to update the machine status, PMAC creates an error since the UI queries the M variables.

//******************************************

Instead of comment out the PMACCom("CLOSE");
//PMACCom("CLOSE");
you can change it to PMACCom("M30"); But not the first Close command in the top of your program

or you can make a BIIG delay (10 sek or more) before all the the PMACCom("CLOSE"); and
if it makes a different
Reply
#29
Hello,

I have written many HMI's that use DPRam and the BinRot to download millions of lines of NC code... actually running programs for weeks at a time on a single machine.

I have a good example application showing basics of doing this both with ASCII and Binary type buffer.

But it is written in Visual Studio and using PcommServer

If this will help you I be glad to give you a full copy with source.
-I have attached a pdf that describes this demo app...

Are you connected to PMAC with USB or Ethernet ?

Can you show me the line of code actually sending the line to execute to the buffer ?

I'm confused reading all the posts above... and not sure what is or is not working ?

Can you describe simply what IS and what IS NOT working ?

I also have some examples of using PMAC Interrupts and data gathering techniques.

Note that with my NC hmi I use multiple threads, one to send the data to the pmac buffer, and a different thread to update the HMI to watch motor positions, status, NC line number executing, and even draw on simple 2D graphics the motion as it is executing...


Thanks,
mike


Attached Files
.pdf   PComm2 Delta Tau Example HMI Program.pdf (Size: 425.03 KB / Downloads: 65)
Reply
#30
(11-29-2013, 10:30 AM)Unit101 Wrote: Hello,

I have written many HMI's that use DPRam and the BinRot to download millions of lines of NC code... actually running programs for weeks at a time on a single machine.

I have a good example application showing basics of doing this both with ASCII and Binary type buffer.

But it is written in Visual Studio and using PcommServer

If this will help you I be glad to give you a full copy with source.
-I have attached a pdf that describes this demo app...

Are you connected to PMAC with USB or Ethernet ?

Can you show me the line of code actually sending the line to execute to the buffer ?

I'm confused reading all the posts above... and not sure what is or is not working ?

Can you describe simply what IS and what IS NOT working ?

I also have some examples of using PMAC Interrupts and data gathering techniques.

Note that with my NC hmi I use multiple threads, one to send the data to the pmac buffer, and a different thread to update the HMI to watch motor positions, status, NC line number executing, and even draw on simple 2D graphics the motion as it is executing...


Thanks,
mike

Hi Mike,
I had followed the same logic as you have in the example.

I have a thread for updating the machine status and I have a subprogram which is called by the thread every 50ms. So once the user clicks on the send buttons, a set of lines are first sent immediately after open buffer command. Soon after that, R command is given and the PMAC executes the NC lines sent to the buffer.

So after this first set of NC codes, the control moves to the update thread, in which the same logic of sending lines is performed. During sending the lines, the machine update thread is disabled. and after the lines are sent, the subprogram enables the thread back.

Now the issue is, if I use the same logic but without using the CLOSE command in between anywhere, all the lines are executed perfectly. But no update of the machine status is possible since the buffer is open.

But if I CLOSE the buffer after sending the required number of lines, the motion execution is achieved until the first CLOSE command with remaining few lines still in the buffer which is identified from the PR command.

So my main issue is to CLOSE the buffer intermittently to update the machine status and also the executing lines info.

I'm using USB communication.

So following are the set of program which I had written to send the NC codes:

if(PR<750)
{
for (int i =0; i<=(1500-PR); i++)
{
PMACCom(String[LineIndex].c_str()); // Sending the NC codes here
LineIndex++;
if(LineIndex>=(total_line_count))
{
PMACCom("&1B0R");
firstRUN = false;
PMACCom("CLOSE");
tmrUpdateMachineState->Enabled = true;
return;
}
}
if(firstRUN ==true)
{
PMACCom("&1B0R");
//PMACCom("CLOSE"); // if I comment this and disable the machine timer, everything works fine
firstRUN = false;
sub_function(); // calling the sub-function here
}


Sub_function

if(PR<750)
{
tmrUpdateMachineState->Enabled = false;
//PMACCom("&1 OPEN ROT"); //Want to use the Open and close buffer in the sub-function so that i can
// Update the machine status
for (int i =0; i<=(1500-PR); i++)
{
PMACCom(String[LineIndex].c_str());
LineIndex++;
if(LineIndex>=(total_line_count))
{
PMACCom("CLOSE");
tmrUpdateMachineState->Enabled = true;
return;
}
}
}
else
{
PMACCom("CLOSE"); // if I comment this and disable the machine timer, everything works fine
tmrUpdateMachineState->Enabled = true;
return;
}
Reply
#31
(11-29-2013, 10:30 AM)Unit101 Wrote: Hello,

I have written many HMI's that use DPRam and the BinRot to download millions of lines of NC code... actually running programs for weeks at a time on a single machine.

I have a good example application showing basics of doing this both with ASCII and Binary type buffer.

But it is written in Visual Studio and using PcommServer

If this will help you I be glad to give you a full copy with source.
-I have attached a pdf that describes this demo app...

Are you connected to PMAC with USB or Ethernet ?

Can you show me the line of code actually sending the line to execute to the buffer ?

I'm confused reading all the posts above... and not sure what is or is not working ?

Can you describe simply what IS and what IS NOT working ?

I also have some examples of using PMAC Interrupts and data gathering techniques.

Note that with my NC hmi I use multiple threads, one to send the data to the pmac buffer, and a different thread to update the HMI to watch motor positions, status, NC line number executing, and even draw on simple 2D graphics the motion as it is executing...


Thanks,
mike

Also let me know if I need to put in lot of effort if I use BIN Rot or DPRAM option for sending the ASCII code. Can you share the PMAC interrupt and data gather option as well. I would request you to suggest me the easier option so that i can wind-up this project
Reply
#32
(11-29-2013, 11:12 AM)Raghav Wrote: Also let me know if I need to put in lot of effort if I use BIN Rot or DPRAM option for sending the ASCII code. Can you share the PMAC interrupt and data gather option as well. I would request you to suggest me the easier option so that i can wind-up this project

It is not easy for me to tell how to do in C++, because I write my software for IPAD in objective C, but my experience is : Do not send the "CLOSE" command before PR is 0.

Jorgen
Reply
#33
Go here to get full example HMI.
https://www.dropbox.com/s/ktkqk05njfgbjj...n=12757969

I see you have a function PMACCom() but this does not show me what/how you are sending lines to pmac buffer ?

I assume you have a line like this ?
Pmac.DPRAsciiStrToRotEx(m_nDevice, command, 0, bufSendImmediate, out status);

What is "bufSendImmediate" set to ? True, False ?
I think this is you issue....

Since using USB you need to set this value to "FALSE" until you are ready to send the LAST set of lines to buffer, then you set this to TRUE.

It is a bit tricky but look at example code:
private void loadNcToBuffer() function closely...

Look at the do-while loop that contains the Pmac.DPRAsciiStrToRotEx() function, you can see that the "bufSendImmediate" is changed while downloading....

Thanks,
mike
Reply
#34
(12-02-2013, 06:35 AM)Unit101 Wrote: Go here to get full example HMI.
https://www.dropbox.com/s/ktkqk05njfgbjj...n=12757969

I see you have a function PMACCom() but this does not show me what/how you are sending lines to pmac buffer ?

I assume you have a line like this ?
Pmac.DPRAsciiStrToRotEx(m_nDevice, command, 0, bufSendImmediate, out status);

What is "bufSendImmediate" set to ? True, False ?
I think this is you issue....

Since using USB you need to set this value to "FALSE" until you are ready to send the LAST set of lines to buffer, then you set this to TRUE.

It is a bit tricky but look at example code:
private void loadNcToBuffer() function closely...

Look at the do-while loop that contains the Pmac.DPRAsciiStrToRotEx() function, you can see that the "bufSendImmediate" is changed while downloading....

Thanks,
mike

Dear Mike,
Thank you for your reply. Currently I'm using the ASCII communication with "DeviceGetResponseEx" command. PMACCom calls this function.

In this case how do I send the command to the buffer and also update the coordinates? In the Pcomm application you had sent me, the machine coordinates are update while using non-ascii communication alone and that too using the "GetNetActualPosition" which I'm unable to find in the PCOMM32.dll calls. Also in the ASCII communication in your code, I'm unable to see any "CLOSE" command for intermittent machine coordinate updates.

So should I use only the DPRAM option to update in real-time? Kindly advise.
Reply
#35
My recommendations:

1. Be sure to use the latest PcommServer, not the older pcomm.

2. Use DPram for ALL but most simple and basic communication with pmac.
- you might use getresponse to send an "occasional" command to pmac but NOT when doing buffer and move downloads while running the machine !... here ONLY use DPram to work with pmac.

-you simply set up registers of data in pmac dpram to hold all the data you want, then in pmac perhaps in a plc you update these registers as often as needed.... then on PC side you simply get a group of registers at a time and bring them over, then parse the data out...

-so with a single command on PC you can get 100's of registers from pmac with data such as motor position and status...

-below is another example application that shows exactly how to do this... look for the function GetDPRWords()

-it takes a bit of work to set this up, but once you do all the data in PMAC is easily available to your application.... and with very low overhead on the system and communications

-I have also attached a doc on the comms with PcommServer

-since changes in company we don't use dropbox anymore, for example application please simply email me directl



Thanks,
mike


Attached Files
.pdf   Guide-PMAC-Drivers-Setup-2013.pdf (Size: 202.14 KB / Downloads: 50)
.pdf   Guide-PMAC-Communication2012.pdf (Size: 1.1 MB / Downloads: 57)
Reply
#36
(12-04-2013, 05:34 AM)Unit101 Wrote: My recommendations:

1. Be sure to use the latest PcommServer, not the older pcomm.

2. Use DPram for ALL but most simple and basic communication with pmac.
- you might use getresponse to send an "occasional" command to pmac but NOT when doing buffer and move downloads while running the machine !... here ONLY use DPram to work with pmac.

-you simply set up registers of data in pmac dpram to hold all the data you want, then in pmac perhaps in a plc you update these registers as often as needed.... then on PC side you simply get a group of registers at a time and bring them over, then parse the data out...

-so with a single command on PC you can get 100's of registers from pmac with data such as motor position and status...

-below is another example application that shows exactly how to do this... look for the function GetDPRWords()

-it takes a bit of work to set this up, but once you do all the data in PMAC is easily available to your application.... and with very low overhead on the system and communications

-I have also attached a doc on the comms with PcommServer

https://www.dropbox.com/s/bv8rroh7j7l871...120413.zip



Thanks,
mike

Dear Mike,
I had tried to use the "DeviceDPRAsciiStrToRotEx" command instead of the getresponse, but the NC codes are not executed at all. These are the calls I used to initialize the DPRam and for PR value I used "DeviceDPRProgRemaining".

ENABLE/DISABLE ROTARY BUFFER
EnabDisabDPRCom(int state)
{
if(state ==1)
{
DeviceDPRRotBufChange(noOfDevice, 0, BufferSize);
DeviceDPRRotBuf(noOfDevice, 1);
}
else
{
DeviceDPRRotBuf(noOfDevice, 0);
DeviceDPRRotBufRemove(noOfDevice, 0);
DeviceDPRRotBufClear(noOfDevice, 0);
}
}

OPENING THE ROTARY BUFFER
PMACCom("M999->DP:$60F48");
PMACCom("UNDEFINE ALL");
PMACCom("A");
PMACCom("&1");
PMACCom("Q CLOSE I9=0");
PMACCom("CLS");
PMACCom("CLR");
sprintf( strCom, "&1 DEFINE BIN ROT %d",(BufferSize/2));
PMACCom(strCom);
PMACCom("DELETE TRACE");
PMACCom("DELETE GATHER");
PMACCom("&1 DEFINE LOOKAHEAD 1000,500");
PMACCom("&1B0");
PMACCom("&1 OPEN BIN ROT CLR");

SENDING ASCII COMMAND
EnabDisabDPRCom(1);
OpenRotBuffer();
RotaryBuffer=1;
LineIndex=0;
firstRUN=true;

long PR = ProgRemaining();
if(PR {
for (int i =0; i<=(BufferHighLimit-PR); i++)
{
bool bufstate = false;

command = "M999==" + AnsiString(LineIndex+1);
PMACRotCom(bufstate, command.c_str());
if(i == (BufferHighLimit-PR)) bufstate = true;
PMACRotCom(bufstate,reditMain->Lines->Strings[LineIndex].c_str());
command = "";
LineIndex++;
if(LineIndex>=(total_line_count))
{
PMACcontrolObj->EnabDisabDPRCom(0);
if(firstRUN ==true)
{
PMACRotCom("&1R");
firstRUN = false;
}
tmrUpdateMachineState->Enabled = true;
return;
}
}
if(firstRUN ==true)
{
PMACRotCom("&1R");
firstRUN = false;
tmrUpdateMachineState->Enabled = true;
}
}
}

TIMER EVENT
Above code is repeated in this. I'm not closing the buffer anywhere in the code. I disable the DPRAM option at the end of the NC code execution. So I'm not sure whether I can use the "getresponse" command to update my UI or do I need to set-up the M variables as you had mentioned above.

Since the all the programming is completed using Pcomm32.dll and only this rotary buffer issue is pending, I would like to continue with Pcomm32.dll as of now and use the DPRam functions.
I tried to execute the NC program, but no motion is achieved. Also it shows that all the NC codes are sent to the PMAC. I'm not sure where and what is the mistake I'm making as i'm pretty new to DPRAM option. I would like to get your help in setting up the DPRAM program.

The code sample which you had sent is created in newer version of visual studio and I'm unable to open it. I currently have VS2008.

Looking forward for your suggestions in this regard.
Reply
#37
I resent you link to example that demonstrates in a simple way the method recommended to work with Binary Rotary and Ascii buffer and DPRam for VS2005.

I includes pmac code as well so with this example you should be able to create a simple version of what you need to do.

I strongly suggest you work to get the example running then I'm sure you will best understand how to implement similar logic in your more extensive machine code.

If you have trouble with example let me know I can help you with this since I have same code. Helping you with your larger program is very difficult since we only see code snippets and not the whole thing.

The secret is to first get the logic working in as simple a system as possible... then build from there.

Best Regards,
mike
Reply
#38
(11-29-2013, 10:30 AM)Unit101 Wrote: Hello,

I have written many HMI's that use DPRam and the BinRot to download millions of lines of NC code... actually running programs for weeks at a time on a single machine.

I have a good example application showing basics of doing this both with ASCII and Binary type buffer.

But it is written in Visual Studio and using PcommServer

If this will help you I be glad to give you a full copy with source.
-I have attached a pdf that describes this demo app...

Are you connected to PMAC with USB or Ethernet ?

Can you show me the line of code actually sending the line to execute to the buffer ?

I'm confused reading all the posts above... and not sure what is or is not working ?

Can you describe simply what IS and what IS NOT working ?

I also have some examples of using PMAC Interrupts and data gathering techniques.

Note that with my NC hmi I use multiple threads, one to send the data to the pmac buffer, and a different thread to update the HMI to watch motor positions, status, NC line number executing, and even draw on simple 2D graphics the motion as it is executing...


Thanks,
mike
Hello,

I using the DPRAM binary ROT recently,but I don't complete the function of this.There is a problem that bothers me.When I down load the file to the DPRAM ROT,then the PMAC will get the file text from the DPRAM ROT to the internal ROT .The file awalys down load to the DPRAM ROT completely .But there are awalys some file don't down load into ROT in the PMAC.Maybe I don't understand the mechanism of the DPRAM Binary ROT and ROT.and I can't down load the PDF file for your privided. Can you give me the documents about this .
Thanks
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)