Sim Slowdown

[bstern]

Hi All, I am making progress on an MS Access package that takes my cut list from KCDW and generates shopbot code for the way I build my closets. My problem is that when running the code - say 5 sheets worth - the simulator slows way down. You can see it starting to slow during the the middle of the first sheet after drilling a set of holes.

I thought it had something to do with the "movement blocks'. I inserted "SC,2" at the beginning of each sheet. No help.

Any thoughts on why it slows? Can I expect communication problems once I go into production?

On another note, how accurate is the Total time that it outputs at the end of a file in the simulator?

Thanks, Bob

[andyb]

Bob, I have a few questions.

1. Is this the PC that controls your bot or just your design PC?

2. When previewing is the Tool Visible checked? The PC that controls my bot has a 1.2 gig processor and my design PC has a 1.4 gig processor. My design PC slows down when I go into preview mode and have the Tool Visible, checked. If Tool Visible is checked, uncheck it to see if that helps. The files that caused me problems on my design PC run fine on my control PC.

3. What other software is running? If you have MS Access, anti-virus, or other programs running you are using up your system resource. Most all MS application are resource hogs and didn't like to give them back. When system resource are low your system will run slow.

Is long as the PC you are using to control the bot has nothing else running but the control software I think you'll be OK.

Andy B.

[bstern]

Hi Andy,

1. Right now, I am running it on a Dell M90 laptop 1.66GHz with 2 GB Ram.

2. Simulate checked, tool visible not checked.

3. No other Ap running. Shut down Norton AV, no help.

When I go into production I will have a dedicated PC for the bot.

Its taking 20 to 30 Min's to do an 18min job simulation.

[Brady Watson]

Make sure you have the latest version of DirectX.

-B

[bstern]

Just upgraded to 9.0c - no help

Seems to write to the disk at every command.

[andyb]

Bob,
Norton, don't get me started on my dislike for them. I used to swear by them. I think Norton took a lesson from McAfee when it comes to installing their software. Norton installs so many components that if you shut it down you are only shutting down the active scanning. There are still other Norton components running in the background.

I agree with Brady. Make sure you're running the latest DirectX.

Andy B.

[bstern]

I had this same problem on a fresh laptop without Norton installed. I have turned off all options in Norton now.

This seems to happen when doing allot of drilling.
When it happened before I was just checking the estimated time to do 6 full length 32mm drill runs per sheet. Never could get it to finish.

[harryball]

On mine, the longer a sim runs the slower it gets. It's useless on anything but small runs. I generally leave siumulate unchecked for that reason. I have found if you keep the size of the preview window small (very small) it helps. No amount of tinkering with my PC fixes it and it performs the same on 3 different systems. Since it's not a critical issue for me I ignore it.

Robert

[Brady Watson]

Bob,
You'll want to turn off the 'animate' feature to speed things up. The previewer gets really slow on large 3D files, but everything 2D should be pretty quick.

-B

[myxpykalix]

Bob,
Bruce Clark wrote a shopbot part previewer standalone. Maybe do a search and try your parts in that to see if you have the same problems?

[bstern]

My purpose for using the simulator was to watch what the code I generate was doing in what order. Jack if you are talking about the shopbot Previewer it's what a finished file would look like.

I am in need of a tool that will show me how my code works. The Simulator is perfect, just bogs down for some reason.

[myxpykalix]

I know almost nothing about code language and all that, but since Bruce developed this he may have some insight as to what might be going on. Also there are utility programs for windows that track graphically processor usage, memory allocation and other functions. I know i've seen them, i just can't name one. That might help?

[jason_fullmer]

Try www.visedit.com (http://www.visedit.com), it shouldn't have a problem slowing down and you can step forward/backward to see the simulation. Also you can set a "breakpoint" run it without simulation to the point (fast) and then run it with simulation to see what it is doing.

I am finishing up the CA,CC,CP,CG,CR and MD commands right now... if your file contains any of these, let me know and I can email you a special version.

[bstern]

I talked with Scott at Shopbot today.
I got a pretty lame answer. "it depends on your memory". When pressed he said it was a problem of rendering the jogs and that if I changed all my jogs to moves it would fix the problem for viewing.

No Go, after editing out all jogs its maybe slightly longer before the inevitable slowdown.

I have been getting great support from Shopbot in the past. Today the attitude was: ya..so.. that a fact it slows...

I guess I was waiting for something like, yes we are aware of the problem. (or any acknowledgement that is in fact a problem)

I am just going to have to copy out parts of the code and run it in small chunks to see what is going on. It will slow me down, but not kill me.

[jason_fullmer]

Bob,

Did visedit not work for you? If there was a problem - would you mind sending me the file(s) and a description of the problems so I can fix any issues?

[henrik_o]

Bob,

I've never experienced this particular problem myself, but I have seen some behaviour that would make me question whether the SB3 previewer deploys a 'clean' OpenGL environment or if it's a non-updated implimentation or even something non-OpenGL altogether. A few times, I've seen what looks like the oldskool "chase/stutter upkeep loop", whatever, reminiscent of VRML.

Jason can correct me on this, and probably shine a lot more light on the particular engines at work. From what I could tell playing with VisEdit, it's clean OpenGL in there. Buffers should not be a problem.

Speaking of VisEdit, Jason, I'm sorry I didn't get back to you on that. I felt I really needed the machine to articulate any questions worth your time. Now that I have it, I'd very much like to purchase it, if you're at that stage.

[bill.young]

Hey Bob,

I've been on the road for the last couple of days and am just getting a chance to catch up...

As you've realized, the Previewer in simulate mode is not "realtime", in that it doesn't get it's timing from the move speeds of the tool but is pretty much a function of how fast your computer can read and write files and how fast it can draw. We do control the speed a little and tried to pick a simulate speed that was a compromise between "too slow to be usable" and "too fast to see what was happening". Oddly enough most of the feedback we've gotten has been from people that run smaller files and complain that simulate mode is too fast for them to see what they want.

We've put a lot of work into making the non-simulate preview run faster in the last couple of versions and have made a lot of headway with that. There may be some tweaks that we can do with simulate mode to speed things up without making the "make it slower" guys mad...if you can email your file to me I'll see what I can do.

Bill

[bill.young]

Henrik,

You're absolutely correct...the previewer is all done in VRML using Parallelgraphic's Cortona Viewer. I think we've gone about as far as we can with VRML, though, and are looking into other options, OpenGL being one of them.

Bill

[jason_fullmer]

Henrik,

Yep, VisEdit is using OpenGL, and although there is quite a bit going on... I try to keep it as "clean" as possible. I just ran a .sbp file with about 140,000 lines and it took 55 seconds in the Shopbot preview and 18 seconds in VisEdit. I haven't looked at speeding up performance much, so I'm sure there is room for improvement. The other interesting thing was when I rotated and zoomed in on this image in Shopbot, the preview crashed on me.

As far as being ready to purchase - I'm not quite there. Some other posts about software have made me nervous and I want to solidify a few areas, and I also want to outline exactly what VisEdit does, and what it does NOT do. So the customer knows exactly what they are purchasing. The plan is to release a beta version in the next few weeks and then hopefully be ready with version 1.0 in a couple months.

[bstern]

Hi Bill,

You bring up a good point. When I first start the sim it works a bit fast. I think that speed is a good compromise. I have had to replay a start once or twice to be able to see what is going on. Then it starts a decline in speed. After the 3rd sheet of parts its almost useless.

I will email you a file.

Jason, I will check out Visedit and see how it performs.


My eyes are a bit blurry from coding. I'm not a programmer at all. I can just write query by example and reports in access. This is my first foray into variables and subroutine's (shopbot code.) I have cutting, onion skinning and drilling done and should have rafix boaring and clean up done in the next 2 days. Thank God closets are fairly simple construction.

Its been a long strange tip but, rewarding to see the amount of shopbot code coming out a single push of a button!

On to the machine by end of next week.

Thanks, Bob

[myxpykalix]

It seems to me that if your machine is up to date enough to be able to play video games in a open gl environment jasons previewer should have no problem. I recall being able to zoom in real time to see the bit going over the peaks and valleys of the carving file i was previewing. I had no problems.

[beacon14]

I have the same problem with the previewer slowing as the file progresses with all three of my computers. I've pretty much stopped using the "simulate" option.

[henrik_o]

Bill Y,

This being pure VRML I guess I’d have to be pretty amazed you’ve managed to carry it this far and so well; I know nothing about that environment from a dev perspective but haven’t ever heard much good from those I know who do. For curiosa, was there some parallell motives for adopting that environment, like web cross-overs?

Jason F,

It does look/feel very clean. What engine are you using?

On the to-market aspect, I think your prudence is laudable, even if it were not for the recent drama.

That said;

Bill Y and Jason F,

Maybe you guys should talk. This coming from a total outsider who can’t reasonably apprehend your respective motives/needs and expectations in the sb code edit/previewing department, but it really does seem that there’s some kind of match possible here.

On the one hand, Bill Y/Shopbot seems to feel they’re at way’s end with the current engine. Creating a new from scratch is going to be a major undertaking, and let’s face it, a better editor/previewer ain’t gonna sell more shopbots. What you guys are doing with the projectwizard etc is spectacular imo, and that has the potential to move hardware. It may be a false dichotomy, but if resources are limited I think you’re much better off concentrating on the latter and all the other amazing work you do. At the same time, the current implimentation has a touch of the arcane, and will eventually need to be updated anyway, since users self-report problems with it. Having a spiffy shiny editor/previewer may not move machines, but it certainly puts a certain polish on the system and brand and keeps the installed base happy. Normally, there would be no alternative to developing from scratch, the only real question being in-house or outsourced. However, an opportunity may just have arisen…

On the other hand, Jason is (afaict) very near completion of a very competent editor/previewer. The majority of the actual developing has already taken place, which in economical terms translates to costs. However, quite a lot remains to do to recoup these costs and achieve a return on investment. The developing may be done (or nearly so) but that’s just one half of the equation, now you need to market, process sales, and support your product. While it wouldn’t surprise me if the splash of a new editor/previewer may move say a hundred copies, after which it may level off to a trickle, those copies are not pure profit because you will still have to devote resources (cost) to administration and support. Further complicating this is the fact that you do not currently own a shopbot. While that may not impede support, there is a certain risk it could become a significant factor. There’s also the risk that Shopbot suddenly comes out with a new version that has some killer feature. I ain’t a developer, but if I was and were at the stage you are in, were a corporate entity to suddenly step in and offer to take it off my hands for a set cash sum, I would very seriously consider that. Spending time developing is fun fun fun. Spending five hours on the phone plus two dozen emails with a single customer only to in the end find out their new printer fubar’ed some dll’s is shouldn’t have, and then they ask for a refund, that’s … breathes heavily … n o f u n a t a l l

(Hey I know the singer from that band, ‘No Fun At All’ that is, he’s also named Henrik, they did some US tours fronting for Green Day etc iirc, anyone heard of them?)

OK, I’m done poking my nose where it doesn’t belong. Maybe some of this makes sense; I wouldn't be surprised if it does not.

[henrik_o]

Bob Stern,

Maybe it’s been fleshed out before on this forum, but I for one think your CAM sounds very interesting. I don’t really know what KCDW outputs, but if you’re using Access to post-process, I imagine the ingoing code must be pretty straight forward. I will assume it does not nest?

What are your thoughts on your project, distribution-wise? Is this something you’d be willing to share (with the possibility of others adding functionality) openly, or would you be interested in selling it?

You say you’re doing closets, one market for me (a minor one but still) is bookcases, I think it’s a reasonable fit, and I have been looking into Rafix. What version of KCDW is needed for your CAM solution to work? (I’ve never really looked at it other than casually browsing their homepage.)

[kirkkelsey]

Interesting comment about the "amount of memory" affects the slowdown. I have 4gb, the max for Windows XP, and any sheet nesting with shelf holes slows down so quickly that I have to abandon any simulation.

I need to check my coding not only to see that it cuts what I designed, but that it cuts it in the order and method that I think I have programmed for the ShopBot. I code nested sheet material, and I need to verify the software I am using really outputs the ShopBot code as it shows in its preview. Hence, I can not just turn off the simulate and rely on the result.

Just downloaded VisEdit, and hope this will let me simulate the code, as it is embarrassing when my coding does not cut what and how I say it will.

[bill.young]

Hey Kirk,

You might try one of the other Renderer options for the Previewer in the VP menu item. The default is DirectX but sometimes the OpenGL or the native R98 renderer can be faster. I'm not confident it will help but might be worth a shot...just make sure that you restart the ShopBot software after making a change.

Bill

[bstern]

I stumbled across a great workaround for my original problem!

Insert a "ST" command and the sim clears all past traces. This assumes you have not messed with your x any y locations and have no need to look at the trace after your done.

I was experimenting using the VA command to make adjustments for the offset of my 2nd Z. Poof all traces erased and speeds right along.

It really paid off as my workaround was to edit my code and play on sheet at a time. After playing 4 sheets in a row I spotted where the code asked for a bit change and the immediately asked for the bit to be changed back. I would have felt pretty frustrated Changing bits back and forth.

I think using a combination of the 2 workarounds is sold way of testing.

Henrick, no I'm not going to get into the software business. (distracts from making money!)
I will however be glad to share the basics of what I am doing. The real benefit for me, is to have a system that builds just the way I want it to.
And even more important, is that if I want to change something I can just sit down and do it.

I'm paying up front with hrs for many benefits down the road I hope. Besides I'm getting to know the bot pretty well.