Messages

11

SmoothStepper USB / Re: Smoothstepper and Mach problems

« on: January 10, 2010, 10:48:52 AM »

Setting all the offsets beforehand might not be a bad thing to try. From a Smoothstepper hardware / firmware point of view, I wonder what that might prove? Perhaps I'll try it.

12

SmoothStepper USB / Re: Smoothstepper and Mach problems

« on: January 10, 2010, 09:41:17 AM »

Thanks Graham - I really wish the problem was simply me being a complete idiot, but it isn't. NO I'm not setting a new zero in mid program. I don't even think you can do that, though I've never tried. I'm running a program twice. Running it once in one work offset, letting it finish completely, jogging over to the next position that I want to run the program at, setting zero there, and running it again there. Never have a problem on the first run, usually don't have a problem on the second, but many times I do. I don't know what happens on the third time I try it, since after the first screw up, I just shut everything down and start back up again.  Anyway, the behavior sounds like its the same thing as described earlier in the thread, I'm trying to shed some light on when I think it's occurring most, so maybe Warp9 can have a little light go on that says "Snap! Of course! I have to clear that buffer and send those new values to the registers every time the program is started!" Or at least wishful thinking.

13

SmoothStepper USB / Re: Smoothstepper and Mach problems

« on: January 09, 2010, 05:37:06 PM »

I totally have this problem... but only from time to time. The best way to coax the machine to spaz out in this fashion is to stick down two panels on the machine... Zero it to the first panel and run the program. THEN, I go ahead and jog over and zero it to the next panel. Upon pressing "START" the machine jerks, as if just a pile of pulses get sent out to one or more of the axes, then, even though the DROs are reading right, the machine screams over to the first panel, or at least somewhat, and starts mutilating it. Usually, since I have a slow to spin up spindle, I can catch it before any major damage happens, but I'm always on my toes. The smoothstepper is great and all, but I use my machine to make money, and when I maul a $200 sheet of plyboo because my controller goes haywire...well it just makes my day a whole lot less fun. The real sucky part is that I can't reproduce this problem in any reliable way, but I'm taking notes on when it happens, and it almost always happens after a run and a re-zero, and not when I press start, but when I press start the second time (after the tool change notice) Also, I've never run this machien with any other config files. it's been smoothstepper since day 1.

Anyway, my feedback. I know this thread is old, but I'm kind of at the end of my rope with this.

14

SmoothStepper USB / Re: SS DISCONNECT SAFETY CONCERNS

« on: December 09, 2008, 04:00:08 PM »

Some people sell milk for a living. I make my living from these robots. I may not have spent my entire life building industrial automation, but certainly more than a few years. People are free to question my judgement, call me an idiot, a liar, spit on me, ignore me, etc, etc, etc, but please have some courtesy and don't do it automatically and immediately. I feel like I'm a hippie trying to convince the president that going to war in Iraq is a bad idea with the feedback I'm getting!



"Very good, now set up your enables like they should be and your fault signals like they should be "

and other stuff like

Dont understand this, if you are meaning the SmoothStepper could develop a fault and then send an axis or two or three going wildly out of control then please tell me how the chargepump would stop this happening?"

and better yet

Please give an example of where the chargepump would come into effect with regards mach and then why this would not be the case with the SmoothStepper.


Trust me when I say I've been on Warp9's web site and downloaded the absolute latest version of everything I could after I discovered this problem, only to discover that I already had the latest version of everything.

As far as implementing a dead man switch, watchdog timer, charge pump, whatever, I KNOW it can be done. There's a little blinky LED on the Smoothstepper that's just blinking like mad when it's happy.

I firmly believe that any charge pump and safety circuit should be totally independent of all other boards, and totally analog, and barely keeping its head above water in regards to remaining turned on from the pulse train.  Safety is important, and if you think you can ignore it even on your little piss-ant nema-23 hobby mill or CNC dremel built out of MDF, think again. On top of it all, you have to have those hard, non-computerized stops built in too. Put guards around things and places that can pinch, poke, or crush to a pulp, keep your hands out of the way, use two-hand logic on machines, wear your safety glasses, don't work on stuff when it's live, and don't stick your fingers in places that they shouldn't go.  The Mach3 manual preaches about it, and so will I. When you ignore these things, you'll end up like the last guys I saw - One machine, a nice, cheap Chinese tube filling and sealing machine. Granted, the guys on the production floor are idiots, but this machine chopped off two fingers in one week, and the following Tuesday, chopped off a third. I should give credit where credit is due, and note that this wasn't the same person getting more and more fingers cut off.  The problem finally got tracked down - no interlocks, badly placed sensors, and generally a poorly thought out or poorly implemented safety system.

15

SmoothStepper USB / Smoothstepper disconnect safety concerns

« on: December 09, 2008, 03:12:30 PM »

 

So I tried to report the fact that a smoothstepper will continue to output a pulse train on the charge pump even in the event of an error in Mach...even in the event of a serious system crash, even in the event that I tear the power cord from the computer. Not only that, it will also continue to jog the machine into oblivion if you happen to be jogging when this happens - Power failure, cord ripped out, the extremely unlikely scenario of windows crashing, etc.

I reported this on the Warp9 forum, and all I get is flack.

As you can see, my machine isn't a sherline with stepper motors scavenged out of floppy drives. If I had not set up the limit switches directly in to the servo amp, which by the way folks, don't EVER forget to do this if you can, but if I had not, it would have slammed 1KW/3KW peak of power in to pure bashing, crushing excitement.

With a working charge pump, this would never have happened.  If I had powered the smoothstepper from the PC, true, in the event of a power failure, this would never have happened either. but then again, with all the other boards, MPGs, analog spindle controls, etc, I have to use an external 5V supply for them all, so no smartie pants telling me that USB power is the solution to my problem.

My system is set up seriously. All my amps have and use "Servo Enable" inputs from one line out of Mach. They have logic and motor power input. Logic is always on. On top of servo enable, the motor power input wires, all three phases, go through a contactor on yet another enable line.  The spindle has a contactor AND a VFD, each on their own I/O lines, and all of this goes through my E-stops AND charge pump enable.  The servo fault lines and spindle fault lines all go in to an external e-stop input on the PLC. This is a big, dangerous machine, and I can't afford to drop $10K on a new Fagor controller.

16

General Mach Discussion / Re: Newby with a question about Spindle Step/Dir setup

« on: October 19, 2008, 11:27:52 PM »

Sounds like something that needs to be addressed in Mach. I've got a tormach that runs Mach3 - It's got the analog spindle. They run it as step/direction though, and I assume that the step signal must just go in to some charge pump or something and get fed in to the VFD as an analog signal.... but same deal. An increase in speed is nice and gentle. A decrease bumps, thumps, etc. I assume with a true servo, this would be a pretty violent thing.

I notice that on the VFD, I have to set the decel pot carefully. I needed a replacement VFD back a few months ago (under warranty YAY!) and I had to tune it. The Accel pot could be set almost anywhere, because Mach was ramping it up, but if I set the Decel pot wrong, when I reduced speed a lot or stopped, the VFD would error out with an overvolt. The motor was generating too much juice in the process of slowing down too quickly, and was literally acting like a generator. They all (motors) do this of course, so it needs to be addressed.

17

Video P*r*o*b*i*n*g / Re: More Lasers = A Better Scan

« on: October 19, 2008, 11:09:57 PM »

Sure I can give you the software - Or at least the source code. It was all done in VB6.

The problem is, it's probably going to be useless for any other purpose besides scanning boots. It was super purpose-built - There's no video interface, no VFW support, nuthin. I ended up frame capturing something like 2000 frames of video and writing them up to sequentially numbered BMP files. The file name, numbers, and location on the disk were all hard coded in to the software, AND I built all the screens to run on a dual monitor setup. Also, it was several programs. All one did was look at the images and do the remedial signal processing on it... It was horribly slow an inefficient, so much so that I actually broke up the data in to two sets and ran the program in two instances so I could utilize both CPUs. It still took all day, but again, it only had to work once. It would have taken me 3 days to write the software better.

Actually... I think I might have trouble finding the source code. Here are the executables. There's something else that goes with it - The data file of the boot. I'll see if I can dig it up. It's on a CD somewhere I know.  I don't remember the format - at all, and there's no documentation. If I can find it, I'll upload it, AND now that I think of it, I don't think that there's much in the way of source code left either. Who knows.... again I'll upload it if I find it, but its mostly useless, I hate to say.

Andy

18

General Mach Discussion / A definitive answer on dual processors...

« on: October 08, 2008, 01:03:33 PM »

A definitive answer on dual processors...

I'd like to know the following... this would probably be a question directly for Art. I looked around on the forum and haven't found much on this.


IF I have a dual processor system, IS there a process, specifically the pulsing engine or whatever, that I can select, and give high priority and affinity to one processor, so as to avoid hiccups when I do something rash like zoom in on a tool path or change screens while the machine is running?

Any thoughts?

Andy Baker

19

Video P*r*o*b*i*n*g / More Lasers = A Better Scan

« on: September 16, 2008, 03:42:22 PM »

Hello -

So I've yet to hook up the laser scanner just yet, but I have some thoughts and past experience I'd like to share.

Once upon a time I built my own laser scanner. It was awesome, and it used two laser beams.. Well, actually one laser, split in to two beams and then broken out in to lines.  The lines came in from either side of the camera and intersected at zero. Here's why - Any sloping surface greater than whatever the laser angle is will effectively mean an undercut that can't get scanned. This was bad for what I was doing. I didn't need dimensional accuracy as much as I needed an accurate visual representation.  Anyway, I didn't use an XYZ gantry, I used a turntable. It was just better for what I was doing, and anyway, I had one on hand. Here's some pictures. Sorry for the high resolution.



Here's the rig in the flesh.



I had a little layout breadboard table I made out of ply. Good for this sort of thing. All the optics were affixed to the various stands. The laser was a big fat 50mW 650nm red - Plenty of power to go through all those lenses and still be seen by the camera. I photoshopped the beam a little bit to make it show up in the foreground.

Here's an animated GIF of the single line version. gotta start somewhere!



and here's the resulting point cloud, complete with noise.



After some processing in crappy VB programs written a long time ago by me, you get this.



next up shots of the second scan.  I ended up taking the brightness of the laser and assigning it to the brightness of the point (in the cloud) This kind of let me weight them visually - After all, I was just drawing these on sheets of styrofoam to cut with a jig saw.  You can see on the left that there are purple and yellow points. these represented either laser. Both lines were scanned at the same time. Processing was done from center to left for one laser, and center to right for the other laser. This was NOT two scans, as in scan once, set up again, scan again, overlay.

This one is big - Scroll sideways. Sorry - Screen capturing from dual monitors makes messes like this.



For another part of the scan (for the sole of this shoe) you can really see where two lasers comes in handy. Blue and green represent left and right laser beams.




Now you guys can pick apart my lack of signal processing, inattention to detail, mathematical flaws, geometric laws bent and broken, but the results were pretty spectacular. After all, I was only going to render the scans by sharpie and jigsaw, so why blow weeks on software when I had foam to turn to dust?




Anyway, a little food for thought for producing the next generation of video scanner plug in software.



Also, a question - Can the plugin scan multiple strips and knit them in to one cloud? Solidworks 08 seems to be able to make sense of the mechanical probe-generated point clouds fairly well, and I've got an enormous machine, and it would be good to be able to scan big things.



Andy