Buffers, buffers, buffers I hate buffers....help please

[Colin Gilchrist]

Thanks Reko, I'm looking forward to having you in class.

[ahaslam]

Looked for the class, I know I am about two years late but was thinking you might consider doing another one. 

[Colin Gilchrist]

I've actually been thinking of offering some of the more advanced classes again. The main issue for you will be that you haven't taken the "basic" MP post class yet. Its usually advisable to take that class first. Buffers are a pretty advanced topic, and not geared towards the "beginner". Now it could be that you've learned enough on your own to handle stepping up to learning buffers, but I'm not sure yet. I'll take a look at your other thread.

[jlw™]

I'm in on the basic next time.

[ahaslam]

I'm still waiting for word from the man on the class you emailed me about. Stuff like that takes a long time to get around to. I am thinking about asking to do a reimbursement type thing.

[Daniel_E]

On 4/24/2014 at 11:28 AM, Colin Gilchrist said:

The next thing that you need to thing about is when to write data to the buffer. This is more about learning how the calls to 'pwrtt$' work. When the command variable 'tooltable$' is set to '3', this enables the "Tool Table" output. MP will perform a "pre-read" of the NCI data. During this pre-read, the motion calls (0, 1, 2, 3, 11) are skipped, and only the Tool Change data is read. These are the 1000 (Null Tool Change), 1001 (Start-of-File Tool Change), and 1002 (Actual Tool Change) codes. In addition, MP will read some data from the lines that precede the Tool Change Call. This will include things like Tool Plane Origin, Tool Plane Matrix, Tool Data, ect.

Hi. I'm new to this forum and I see a lot of really good stuff here. I'm hoping someone can help with my situation.

Sorry to dig up an old thread, but this is the only reference I've been able to find to the problem I'm trying to solve. The partial quote above mentions that when MP performs the NCI pre-read, that the motion calls are ignored. I have an application where I would like to analyze the actual tool path geometry before posting the final program.

Is there a way to do this? When reading MP documentation, it states that the "Entire" NCI is processed....which may not be true.

Any input would be much appreciated.

Daniel

[Colin Gilchrist]

3 minutes ago, Daniel_E said:

Hi. I'm new to this forum and I see a lot of really good stuff here. I'm hoping someone can help with my situation.

Sorry to dig up an old thread, but this is the only reference I've been able to find to the problem I'm trying to solve. The partial quote above mentions that when MP performs the NCI pre-read, that the motion calls are ignored. I have an application where I would like to analyze the actual tool path geometry before posting the final program.

Is there a way to do this? When reading MP documentation, it states that the "Entire" NCI is processed....which may not be true.

Any input would be much appreciated.

Daniel

"I would like to analyze the actual tool path geometry before posting the final program".

There "might" be a way to do this, it just depends on "what" you are trying to analyze before posting the final program. Often, there is a way to get what you want, it just might not use the tools/method you expect when you first think up the problem/issue you are trying to solve. So what kind of analysis do you want to accomplish?

 

[Colin Gilchrist]

On ‎2‎/‎13‎/‎2016 at 0:06 PM, ahaslam said:

I'm still waiting for word from the man on the class you emailed me about. Stuff like that takes a long time to get around to. I am thinking about asking to do a reimbursement type thing.

I'd love to have you in class if you can make it. The Basic Post Processing course is scheduled for this coming June. We'll be meeting on Tuesday and Thursday, from 7:30-9:30 PM, Eastern Time. You can email: [email protected] for a copy of the syllabus and payment information...

 

[Daniel_E]

25 minutes ago, Colin Gilchrist said:

"I would like to analyze the actual tool path geometry before posting the final program".

There "might" be a way to do this, it just depends on "what" you are trying to analyze before posting the final program. Often, there is a way to get what you want, it just might not use the tools/method you expect when you first think up the problem/issue you are trying to solve. So what kind of analysis do you want to accomplish?

 

What I need to know is the machined path length for each individual contour (chain of entities) within the program. It would be great if there was an op parameter that contained this data but I've not been able to find one.  So, I've already successfully worked out the logic to calculate this without any difficulty....the problem is doing it BEFORE the output.

The reason for this is an attempt to simplify and automate the programming of our laser. I would like to know the length of the path because this data would change our decision about what power settings to use (primarily for heat control reasons).

[ahaslam]

I haven't seen a quick way to know the tool path length using the MP. A cheat you could use for the time being is by looking at the backplot's info tab. That will tell you the length of feed/rapid time. Adding a "fq" function into your post for user input would allow you to have that info in the MP at the time of posting. There might be a way to pull the info seen in the backplot via C-hook/Net-hook but that's way over my head. If so, you could easily pass that info into the post processor at the time of posting without using a manual input. I do hope someone else knows an easier way though although Colin would have been the first I would have asked. Good Luck.

[Colin Gilchrist]

Due to the way that MP Processes the data, you'd have to get pretty "tricky" to get this to work. The way to do it would be to insert a "Marker" (comment) at the start of each path, using the "Tool Change" block. Then to process the "path" like you've been doing, and then writing the path length to a Buffer File (Numeric), with at least 2 columns of data. One of these being some "key" that you can use to get the correct "path length variable" from the buffer file.

The 'ppost$' Post Block is called after all the NCI data is done processing. In the 'ppost$' Post Block, you'd have to use a String Buffer, and then "initialize" the buffer, using your just written NC File. This would load your entire NC Code File into the Buffer File, in Memory, and then you could "traverse" the String Buffer, looking for your "Comment Marker". (use "strstr" function to determine if your keyword is present on a given line.) Each time you find a Comment Marker, you would then use the identifier from the comment as your "search string". This would require that you use a While Loop to loop through the Numeric Buffer, reading each record (line). When you have "found" the correct line that has the "matching marker", you could then assemble a new Comment String, including your Path Length, and write that String back to the String Buffer that holds your NC File Data. Once you've completed scanning through the String Buffer, and replacing the Comment Strings with Path Comments, you'd save the String Buffer as a new NC File, delete the original NC File, and rename the new NC File as the final output.

If I was going to attempt to do this, I'd budget about 10-15 hours to write the code, test, and debug. And I've been doing this for quite a while. It is no small feat.

[Daniel_E]

1 hour ago, Colin Gilchrist said:

Due to the way that MP Processes the data, you'd have to get pretty "tricky" to get this to work. The way to do it would be to insert a "Marker" (comment) at the start of each path, using the "Tool Change" block. Then to process the "path" like you've been doing, and then writing the path length to a Buffer File (Numeric), with at least 2 columns of data. One of these being some "key" that you can use to get the correct "path length variable" from the buffer file.

The 'ppost$' Post Block is called after all the NCI data is done processing. In the 'ppost$' Post Block, you'd have to use a String Buffer, and then "initialize" the buffer, using your just written NC File. This would load your entire NC Code File into the Buffer File, in Memory, and then you could "traverse" the String Buffer, looking for your "Comment Marker". (use "strstr" function to determine if your keyword is present on a given line.) Each time you find a Comment Marker, you would then use the identifier from the comment as your "search string". This would require that you use a While Loop to loop through the Numeric Buffer, reading each record (line). When you have "found" the correct line that has the "matching marker", you could then assemble a new Comment String, including your Path Length, and write that String back to the String Buffer that holds your NC File Data. Once you've completed scanning through the String Buffer, and replacing the Comment Strings with Path Comments, you'd save the String Buffer as a new NC File, delete the original NC File, and rename the new NC File as the final output.

If I was going to attempt to do this, I'd budget about 10-15 hours to write the code, test, and debug. And I've been doing this for quite a while. It is no small feat.

Thanks for your input. I was considering this method but have started down a different but very similar path. I may end up changing my plans.

I think my current plan is essentially the same as what you are suggesting, but rather than output the entire nc file with "markers", I was thinking I would write to the buffer for each path as it is processed (with the total path length output as the last record). This means that all motion postblocks that would normally output to NC, will now be outputting to buffer instead. After each path is completely output to the buffer (pretract probably), I would first access the final record to get the path info I need, output as needed based upon that info, then directly output from the buffer to NC for the actual motion toolpath. After this, it would repeat until complete.

Does this sound reasonable to you?

 

[Colin Gilchrist]

7 minutes ago, Daniel_E said:

Thanks for your input. I was considering this method but have started down a different but very similar path. I may end up changing my plans.

I think my current plan is essentially the same as what you are suggesting, but rather than output the entire nc file with "markers", I was thinking I would write to the buffer for each path as it is processed (with the total path length output as the last record). This means that all motion postblocks that would normally output to NC, will now be outputting to buffer instead. After each path is completely output to the buffer (pretract probably), I would first access the final record to get the path info I need, output as needed based upon that info, then directly output from the buffer to NC for the actual motion toolpath. After this, it would repeat until complete.

Does this sound reasonable to you?

 

Sure, that sounds reasonable. Just a different method of accomplishing the same task, which is to calculate the path length at the end of the path, then output this data "first" and then output the rest of the motion by recalling it from the buffer. It still requires quite a bit of work on your part, as you'll need to capture the output and write it to the buffer, then scan through the buffer data to get the path length (unless you are dynamically building the path length during Motion output). Still, your method might be a little more "straightforward" from what I was suggesting.