[The Engine Guy]

I seem to be one of the few who didn't care much for Predator.

The nice thing with using the built in simulation is that you can still have many different machines, and the post is not generated until after you have selected the machine you want to cut it on (bringing up the appropriate post processor automatically). You can change between virtual machines in seconds without having to post out the G-code first. I find this to be a very important distinction because if you post out the G-code, and it's not working well, it's very easy to end up accidentally using a program that you had already decided didn't work right by accident, simply because it exists and you must delete it or update it before you move on in your workflow. If the G-code has not been generated but can be brought right into simulation, there is no opportunity to accidentally use the bad G-code because it does not yet exist.

The G code is not brought into the Moduleworks simulation within BobCAD, that runs from the Move List produced, not the G code, it is pretty accurate but not 100%.
What runs OK in the simulation may not be the same in the G code, all depends on how well the PP being used has been setup.

With the built in Bobcad Standard or Pro simulation system, the last step should be saving the G-code, done only after you have verified that it simulates 100% correctly. This reduces the opportunity to mishandle G-code files that may or may not be kosher for the machine to produce the desired result. In my opinion, having this workflow greatly reduces the option for human error in file handling, which is no small probability for those like me who are probably using half a dozen or more different jump drives to transport the files from their desktop to their CNC machine. Once a file has passed the simulation step, then (and only then) I save it as G-code directly to a jump drive. The only place I save G-code to anymore is the jump drive, and every month or so, I wipe the jump drives clean of all G-code files.

Using Predator Backplot doesn`t interfere in any way with your workflow, it only comes into play right at the very end as a final confirmation of the G code, after you have done your simulation and then generated the code that`s where Predator comes into it`s own, simply right click and choose "Edit CNC" and that will launch Predator directly from BobCAD in just the same way that choosing the "Simulation" button in BobCAD launches the Moduleworks simulation, no difference

I no longer save G-code files in an archive at all. Let's say that during the year after the initial run of a part from G-code I make changes to the machine, or I buy a second new machine, the only way to know for sure that it will work properly a year later is to re-post it after re-simulating it from the .BBCD file. Any update I make to the machine or post processor would show any problems that there may be, and they would also adjust the G-code output to reflect those changes so the file works correctly. Since the .BBCD file already has the toolpath strategies ready to go, it only takes a few moments to re-verify that the toolpath simulates correctly and post it to G-code. I know that sometimes .BBCD files don't open 100% properly in future versions of Bobcad, but I plan to just keep any older version on hand and keep the post processor and simulation up to date. So far, it seems that both of those are portable, meaning that I can update on version and then put the same machine/post processor files into the other versions, so you really only have to do it once to cover the same update to several versions.

All in all, I really find the Bobcad/Module Works simulator is much more desirable for my own workflow, where Predator never really seemed to fit in well at all. Obviously, there are many who seem to really like it here in the forums, and I imagine they must have a workflow that accommodates it better.

I think everyone does pretty much as you do above, just the added final checking of the actual G code in Predator which can`t currently be done in the Simulator, I do hope that Burr is right in thinking that a proper backplot facility may be added to the software, hopefully sooner rather than later as it is a must as far as I`m concerned

Regards
Rob
:rainfro: :rainfro: :rainfro:

[mhackney]

Does anyone have a simple example of a VB script in a post getting called? I tried this:

2101. Read entire file after post.
Dim I As Integer
For I = 1 To 100 ' Loop 100 times.
Beep ' Sound a tone.
Next I

which is as simple as it gets. Nothing happens. I can't find any documentation on how to use the program blocks 2001-2099. A simple beep or popup a modal dialog to validate that I have the plumbing working would be very helpful!

Cheers,
Michael

[mhackney]

Ok, digging through the Help and docs in posts/mill/documents I put together what should be the simplest test case to call a script and it is still failing. Here is what I did in my post:

FIRST: I added the line to print a line number, a G and then call the program_block_1:

15. First Machine Setup
" "
"(====================================)"
"(YYY Machine Setup - ",setup_name,")"
"(====================================)"
n,"G",program_block_1
" "

SECOND: I create the simplest script I could for program_block_1:

2001. Program Block 1.
Dim dOffset
dOffset = 28
Mill_SetReturnString(dOffset&amp)

When I run the post, I see this as output:

(====================================)
(YYY Machine Setup - Hole)
(====================================)
N10 G

I expected to see:

(====================================)
(YYY Machine Setup - Hole)
(====================================)
N10 G28

The script should simply return "28"

So, am I doing something wrong? I can't find a single script that I can verify works in my post on V27 and Windows 7. Is this a V27 bug? Does anyone have a post that successfully executes a (preferable simple) script?

[SBC Cycle]

Let's start simple. Just try this post for starters and see if it does something.

[SBC Cycle]

I'm going to assume that it did do something.

Now edit the post and remove the "carriage returns" and Line 2102. until the blinking cursor is in the same position as it is in this picture:
Attachment 251884

Save it, then post again. You'll notice it quit working. The Scripting engine is a bit picky about how things are organized or laid out. I allow at least two carriage returns between my scripting blocks and at least two at the end of the entire post. The same is true for creating Advanced Posting pages. It just needs it for some reason.

[SBC Cycle]

FIRST: I added the line to print a line number, a G and then call the program_block_1:

15. First Machine Setup
" "
"(====================================)"
"(YYY Machine Setup - ",setup_name,")"
"(====================================)"
n,"G",program_block_1
" "

SECOND: I create the simplest script I could for program_block_1:

2001. Program Block 1.
Dim dOffset
dOffset = 28
Mill_SetReturnString(dOffset&)

Your script works fine when I plug it into the post processor I just uploaded. Again, that's with a few carriage returns between the posting blocks. I think you got the gist of it already, you just need to pick up on the little nuances that you will only learn through some testing.

[mhackney]

Wow, I don't know what to think about this...

Here's what I did - I took a clean copy of one of the BobCAD posts and added the code above "just to test". Guess what? It worked fine. So I started copying and pasting from my post into this one to look for the culprit code. I was able to copy everything from the header down and the post script continued to work fine. So then I attempted to update the header and all of a sudden the script stopped working. I have a completely reproducible test case that looks like this:

Original header:
---------------------------------------------------------------------
---------------------------------------------------------------------
--- BobCAD-CAM Post Processor --------------------------------------
---------------------------------------------------------------------
--- Initial Software Version: BobCAD-CAM V27
--- Initial Creation Date: x-xx-xxxx
--- Author: BCC
--- Machine: BC_3x_Mill - Optional Stop at Tool Change
---------------------------------------------------------------------
---------------------------------------------------------------------
--- REVISION LOG ----------------------------------------------------
---
--- 10-21-2013 - ACC - Updated end of file to correctly support
--- sub program file end.
--- 5/28/2014 - Initial Setup for V4
--- 8/18/2014 - ACC - Setup for V27
---
---------------------------------------------------------------------
---------------------------------------------------------------------
--- SPECIAL NOTES ABOUT THIS POST AND MACHINE -----------------------
---------------------------------------------------------------------
---
---
---------------------------------------------------------------------

****Version number MONTH DAY YEAR****
1000. Version Information = Version Month Day Year? "10.0 08 18 2014"

If I change the version number from 10.0 to 1.0 the scripts stop running! I can change the date and even add an extra '0' after the decimal like this:

1000. Version Information = Version Month Day Year? "10.00 10 03 2014"

and it works. I can make the 10.0 into 11.0 or 10.1 or 10.00 and these all work, but 1.0 or 1.00 or 01.00 do NOT work! Very very odd behavior.

[SBC Cycle]

****Version number MONTH DAY YEAR****
1000. Version Information = Version Month Day Year? "10.0 08 18 2014"

If I change the version number from 10.0 to 1.0 the scripts stop running! I can change the date and even add an extra '0' after the decimal like this:

1000. Version Information = Version Month Day Year? "10.00 10 03 2014"

and it works. I can make the 10.0 into 11.0 or 10.1 or 10.00 and these all work, but 1.0 or 1.00 or 01.00 do NOT work! Very very odd behavior.

That is expected (though unexplained) behavior. At the time scripting was introduced, the post version needed to be at least 9.1 for it to work.

[mhackney]

LOL!!!

I thought the Version was MY version for the post. So, since I created my own post, I figured I would start with version 1. No way of knowing that this was used this way. Thanks!

regards,
Michael

[mhackney]

Ok, scripting works perfectly now to launch GWizardE with my post. I do have to have file type mapping of .nc to GWizardE as GWE will not launch with a file path. Here's the script:

2101. Read entire file after post.

'Gather the file name/path
Dim BCC_FILE
BCC_FILE = MILL_GetProgramName()

Sub Run(ByVal sFile)
Dim shell

Set shell = CreateObject("WScript.Shell")
shell.Run Chr(34) & sFile & Chr(34), 1, false
Set shell = Nothing
End Sub

' Execute the program notepad.exe and open BCC_FILE
Run BCC_FILE

Very simple and effective. I tested it both with Post and Post & Save As

Cheers,
Michael

[SBC Cycle]

LOL!!!

I thought the Version was MY version for the post. So, since I created my own post, I figured I would start with version 1. No way of knowing that this was used this way. Thanks!

regards,
Michael

LOL, exactly. It's the little things that make scripting hard. The documentation has come a long way but some explanation of those kinds of things would be nice.

[jrmach]

mhackney,,,
Preditor Editor just saved me from scrapping a 1/2 days work.A thing called "dog-leg rapids" happens every now and then.The tool path looks perfect,the simulation beautiful,Preditor Editor BAM!!!Can't swear it works for all machines,but you can set it up for Haas.This happened with High Speed Pocketing V 23 AND Advanced Rough V 26 today on a part I was programming...There is no way you would ever of caught it,,not even dry run,I got files on both and will provide on request.Can't emphasize enough how much time and grief Preditor version 2 backplotting has saved me over the years.
BTW,thanks again to SBC for showing me how to set up Preditor for dog legs for Haas.