laser pausing in the middle of a straight vector cut

[Gene Jameson]

hi all. been a lurker for a while but now have a question maybe some one can answer. I have 2 Epilog machines, and i notice that they both pause when cutting some straight vector segments. there is no node at that point in the geometry of the shape and the epilog tech offered a less than satisfying reason. This particular cut is a straight line and it is exactly on the x axis. The tech at epilog said that the shape "must" be slightly angled and the encoders cannot respond in such minute increments so it pauses for a pulse then resumes. Picture your laser cutting out a square in 3mm baltic birch. In the middle of one side it pauses for a beat, then continues. This happens even when there are no nodes in that span. I also don't remember this always happening but can't say for sure that it is related to a firmware update. Has anyone else experienced this. Thanks.
Gene

[Kim Vellore]

Gene, if the line is angled it will not have a node. for the square you are having a problem with did you draw it with 4 lines or did you use a square. This could be a quick check to test, just draw a couple of lines with slightly varying angles and see if it pauses when printed.

Kim

[Gene Jameson]

Kim, the square i described was just an example by me to try to over-simplify what i was trying to describe. The shapes i am cutting have a radius at the top two angled sides and a straight line at the bottom connecting the two sides. It looks like a trapezoid but it has a concave top. I cut the same shape on 3 lasers (2 epilog, and 1 universal). one epilog laser stops in the middle of the straight cut at the bottom. the other 2 lasers do not hesitate. The outline i am cutting is one component (a complete closed shape) not 4 lines. I am can use the Pen tool in corel and "trace" the shape, and the new shape cuts without pausing. So i guess i can just re-create the shapes that have this problem, but it will be a hassle because we cut a lot of different shapes, and i don't want to have to redo them all when this problem seems to have started recently. I really just want to understand what in the geometry is causing this and how i can fix it without redrawing the piece.

[John Blazy]

I have had this mysterious "skip" in the cut twice already since buying my rabbit in January. It has only happened at the beginning of a job, in the morning when I started the laser up, and started cutting about ten minutes later. Once warmed up, I have never had a skip in the cut.

So I just assume that maybe the laser has to warm up a bit more, and has to do with expansion/contraction somewhere in the wiring or the tube itself.

I even wondered if it might be a dust particle shaking loose and falling across the beam path somehow.

[Kev Williams]

the shape "must" be slightly angled and the encoders cannot respond in such minute increments so it pauses for a pulse

Epilog told you that? Sheesh....

All any X-Y axis machine does is follow a dot-to-dot plot file, moving from one XY coordinate to the next. The only pause comes from 'tool start' and 'tool stop' commands so the tool can move to the next shape. When coordinates are close together, the machine will run slower than when they're farther apart. But no 'pausing'...

When drawing a square, there's only 5 X-Y coordinates- corner 1 laser-ON, corner 2, corner 3, corner 4, corner 1 laser-OFF. The steppers have absolutely NO reason to stop between ANY 2 coordinates.

I just cleaned the encoder disk on the back of the X stepper on my Explorer, as I had engraving that was shifting. It was plenty dirty, and works fantastic now. Your pause may be a speck of dirt or whatever on your X encoder....

[Gene Jameson]

With regard to the epilog not lasering immediately when the "go" button is pressed, that has always been an annoyance for both of my Epilog lasers but I live with it. If you don't know what I am talking about, on both of my epilogs, when I press "go" first thing in the morning the carriage starts to move as it should but the laser does not fire immediately. It varies how long this period is. I simply stop the job when the laser starts then restart the job. After that it starts fine.:confused: But this is not the issue I am talking about. I have uploaded a short video to youtube (this was done spur of the moment and I normally cut on the vector cutting grid)
https://youtu.be/Ka-I9m9d-2c. During the last segment at the botom, right in the center, the laser head stops for a split second then continues. This stop/start shows up in the cut edge of the piece. it is not terrible but it did not used to happen. When I first got my laser and was still learning, I realized some of my parts had way too many nodes and this was causing a slower than necessary cut, but there is no node along this span. Thanks!
Oh, and the laser (and encoder strip) is clean. I just cleaned it top to bottom while waiting on my laser tube replacement. I do not believe this is related to the new tube, either. it seems to me something in the print instructions sent to the machine

gene

[Kev Williams]

The laser not immediately firing, my LS900 has been doing this for about 3 years now (and it's 11 years old)- in my case it's because the tube is getting old and I have my 'tickle' turned off. Tickle fires the laser occasionally to keep it warmed up.

Mine only does it when first started up in the morning. I always run a quick dry-run just to get the tube firing nicely.

As for your video and the pause in the middle of the line-- Have you checked to see if that line is dead-to-rights parallel to the X axis? It doesn't matter if there's a node in the line in Corel; if the far left Y coordinate is (f'rinstance) 1.2015" and the far right Y coordinate is 1.2010", then the Y stepper will adjust for that .0005", right in the middle (just about where yours did), and when it does, it will slow down briefly to make the change....

[Keith Winter]

So if this was a Trotec, it would appear like the job transmission from the computer isn't able to transfer fast enough to keep up with the laser. Is this Epilog computer controlled in the aspect that the computer always has to be on like a Trotec, or does it have the processor on the machine itself and can run without a computer?


With regard to the epilog not lasering immediately when the "go" button is pressed, that has always been an annoyance for both of my Epilog lasers but I live with it. If you don't know what I am talking about, on both of my epilogs, when I press "go" first thing in the morning the carriage starts to move as it should but the laser does not fire immediately. It varies how long this period is. I simply stop the job when the laser starts then restart the job. After that it starts fine.:confused: But this is not the issue I am talking about. I have uploaded a short video to youtube (this was done spur of the moment and I normally cut on the vector cutting grid)
https://youtu.be/Ka-I9m9d-2c. During the last segment at the botom, right in the center, the laser head stops for a split second then continues. This stop/start shows up in the cut edge of the piece. it is not terrible but it did not used to happen. When I first got my laser and was still learning, I realized some of my parts had way too many nodes and this was causing a slower than necessary cut, but there is no node along this span. Thanks!
Oh, and the laser (and encoder strip) is clean. I just cleaned it top to bottom while waiting on my laser tube replacement. I do not believe this is related to the new tube, either. it seems to me something in the print instructions sent to the machine

gene

[Rich Harman]

... if the far left Y coordinate is (f'rinstance) 1.2015" and the far right Y coordinate is 1.2010", then the Y stepper will adjust for that .0005", right in the middle (just about where yours did), and when it does, it will slow down briefly to make the change....

I can't think of a reason why a slowdown would be necessary just because the change in Y axis is so slight that the Y stepper only needs to move one step during the line. What if two steps were required? would you expect a slowdown at 1/3 and 2/3 of the way through? How about three steps, or four etc...

[Lee DeRaud]

So if this was a Trotec, it would appear like the job transmission from the computer isn't able to transfer fast enough to keep up with the laser. Is this Epilog computer controlled in the aspect that the computer always has to be on like a Trotec, or does it have the processor on the machine itself and can run without a computer?There's still a processor in the laser, doing the realtime control of the steppers/servos: there's no way Windows/USB can handle that, just too much latency. The only question is how much of the job gets sent to the onboard processor at a time.

[Kev Williams]

A lot of raster data can really eat up the megabytes, but vector data is minimal...

In Gravostyle I drew up the same basic shape as is in the video, at roughly the same size and placement
Note that my upper left corner coordinates are X=0" and Y=19.5", as my machine's zero is the bottom left corner...

http://www.engraver1.com/erase2/plotfile.jpg

--then I copied the actual plot file that would cut this, which is below. The first half of the file cuts the shape,
the second half cuts the circle. The shape starts its cut at the bottom left corner. Just read the coordinates in thousandths of an inch,
so the start point is .881" X, 18.468" Y, top left corner is 1.320-X / 19.453-Y, then the machine plays connect-a-dot, quite a bit for the curve. The last 4 coordinates
before the circle are the top right corner, 3.002-X / 19.453-Y, then to the bottom right corner, 3.409-X / 18.468-Y, then
back to the starting point, where the PU (pen up) command comes in, then it moves to the circle. You'll notice there's a lot of coordinates just to make that
small circle, which is only .061" diameter!

And all this data adds up to a whole 957 bytes. Not megabytes, or kilobytes, just BYTES! (and that includes the 'begin/end file' text!)
An Apple IIe can move this much data in 1/10th of a second, so transfer speeds aren't an issue here!

BUT-- if the bottom left Y coordinate was 18.469 instead of 18.468 like the bottom right, then the stepper would have to move one click up on the
way to the bottom left corner, and it WOULD pause briefly when it does! :) -- this is what I think is happening, the bottom line isn't totally level--


----------- Begin file ---------------
IN;PA;
!PZ 1,0,55,6;
VZ 94;
!DR 0;
PU881,18468;
PD;
PD1320,19453;
PD1397,19422;
PD1474,19394;
PD1553,19370;
PD1632,19348;
PD1712,19329;
PD1793,19313;
PD1874,19301;
PD1956,19291;
PD2038,19285;
PD2120,19282;
PD2202,19282;
PD2284,19285;
PD2366,19291;
PD2448,19301;
PD2529,19313;
PD2610,19329;
PD2690,19348;
PD2770,19370;
PD2848,19394;
PD2925,19422;
PD3002,19453;
PD3409,18468;
PD881,18468;
PU;
PU2136,18813;
PD;
PD2126,18814;
PD2118,18819;
PD2111,18826;
PD2107,18834;
PD2105,18844;
PD2107,18853;
PD2111,18862;
PD2118,18869;
PD2126,18873;
PD2136,18875;
PD2146,18873;
PD2154,18869;
PD2161,18862;
PD2165,18853;
PD2167,18844;
PD2165,18834;
PD2161,18826;
PD2154,18819;
PD2146,18814;
PD2136,18813;
PU;
SP;
----------- End file -------------------------

[Lee DeRaud]

I can't think of a reason why a slowdown would be necessary just because the change in Y axis is so slight that the Y stepper only needs to move one step during the line. What if two steps were required? would you expect a slowdown at 1/3 and 2/3 of the way through? How about three steps, or four etc...What he said. The obvious worst case scenario is a 45-degree line, pausing at every step.

In any case, step pulses are going to the stepper motors (or a full two-way command/response cycle in the case of a servo) at thousands of times per second. So if one of them takes twice as long, so what? It's not like you can see the difference between 1ms and 2ms.

[Rich Harman]

if the bottom left Y coordinate was 18.469 instead of 18.468 like the bottom right, then the stepper would have to move one click up on the
way to the bottom left corner, and it WOULD pause briefly when it does! :)

Why do you think the x axis needs to come to a complete stop for the y axis to move one step??? These machines are quite capable of moving two axis simultaneously.

[Keith Winter]

There's still a processor in the laser, doing the realtime control of the steppers/servos: there's no way Windows/USB can handle that, just too much latency. The only question is how much of the job gets sent to the onboard processor at a time.

I believe you but Trotec has repeatedly told me there is no memory on Trotecs and the only processors are the circuits on the control board, aka no CPU. I've gone round and round with them over it trying to figure out issues. They all stay firm to that, tech support and sales.

[Keith Winter]

A lot of raster data can really eat up the megabytes, but vector data is minimal...

In Gravostyle I drew up the same basic shape as is in the video, at roughly the same size and placement
Note that my upper left corner coordinates are X=0" and Y=19.5", as my machine's zero is the bottom left corner...

http://www.engraver1.com/erase2/plotfile.jpg

--then I copied the actual plot file that would cut this, which is below. The first half of the file cuts the shape,
the second half cuts the circle. The shape starts its cut at the bottom left corner. Just read the coordinates in thousandths of an inch,
so the start point is .881" X, 18.468" Y, top left corner is 1.320-X / 19.453-Y, then the machine plays connect-a-dot, quite a bit for the curve. The last 4 coordinates
before the circle are the top right corner, 3.002-X / 19.453-Y, then to the bottom right corner, 3.409-X / 18.468-Y, then
back to the starting point, where the PU (pen up) command comes in, then it moves to the circle. You'll notice there's a lot of coordinates just to make that
small circle, which is only .061" diameter!

And all this data adds up to a whole 957 bytes. Not megabytes, or kilobytes, just BYTES! (and that includes the 'begin/end file' text!)
An Apple IIe can move this much data in 1/10th of a second, so transfer speeds aren't an issue here!

BUT-- if the bottom left Y coordinate was 18.469 instead of 18.468 like the bottom right, then the stepper would have to move one click up on the
way to the bottom left corner, and it WOULD pause briefly when it does! :) -- this is what I think is happening, the bottom line isn't totally level--


----------- Begin file ---------------
IN;PA;
!PZ 1,0,55,6;
VZ 94;
!DR 0;
PU881,18468;
PD;
PD1320,19453;
PD1397,19422;
PD1474,19394;
PD1553,19370;
PD1632,19348;
PD1712,19329;
PD1793,19313;
PD1874,19301;
PD1956,19291;
PD2038,19285;
PD2120,19282;
PD2202,19282;
PD2284,19285;
PD2366,19291;
PD2448,19301;
PD2529,19313;
PD2610,19329;
PD2690,19348;
PD2770,19370;
PD2848,19394;
PD2925,19422;
PD3002,19453;
PD3409,18468;
PD881,18468;
PU;
PU2136,18813;
PD;
PD2126,18814;
PD2118,18819;
PD2111,18826;
PD2107,18834;
PD2105,18844;
PD2107,18853;
PD2111,18862;
PD2118,18869;
PD2126,18873;
PD2136,18875;
PD2146,18873;
PD2154,18869;
PD2161,18862;
PD2165,18853;
PD2167,18844;
PD2165,18834;
PD2161,18826;
PD2154,18819;
PD2146,18814;
PD2136,18813;
PU;
SP;
----------- End file -------------------------

True normally but if something interrupted the file bad memory, processor error, computer bogged down etc even if it's a small file it can cause issues

[Keith Winter]

One more quick question does it happen at certain times of the day, could the laser be getting too hot? When is the last time you cleaned the fans and filters?

[Lee DeRaud]

BUT-- if the bottom left Y coordinate was 18.469 instead of 18.468 like the bottom right, then the stepper would have to move one click up on the way to the bottom right corner, and it WOULD pause briefly when it does! :)Uh, no. The DDA algorithm converts endpoints to a very-high-speed stream of equal-length X and Y steps. If it had to pause every time two steps in X are separated by a step in Y, those oblique lines on the sides would take about 30 seconds each to cut...they don't.

[Lee DeRaud]

I believe you but Trotec has repeatedly told me there is no memory on Trotecs and the only processors are the circuits on the control board, aka no CPU. I've gone round and round with them over it trying to figure out issues. They all stay firm to that, tech support and sales.I use the word "processor" in its more basic sense, not to refer to something worthy of the name "CPU". It's probably just an FPGA or two. And there is memory involved, at least enough to hold a full scan line of raster data. Again, not gigabytes of RAM, just a FIFO chip in the sub-megabyte range.

[Kev Williams]

all machines are different--

I just tried this with my LS900-- I found that it totally ignores a very slight slant until I make steep enough for the stepper to add about 10 clicks spanning the approx. 2.4"... Until then, no clicks at all. How other machines react is anyone's guess! But I see it happen with my tool machines all the time..

[Rich Harman]

I believe you but Trotec has repeatedly told me there is no memory on Trotecs and the only processors are the circuits on the control board, aka no CPU.

They must be referring to the type of memory where you can download the entire job to the machine then run it independently of a computer. The machine itself absolutely must have some memory to store the incoming information and then put it to use. The incoming serial data would be stored, error checked, then sent on to some other memory location to be processed by the controller. When it is no longer of use it would be flushed to free up space for more data. The amount of data required to cut a single straight line is so small that I could not believe that it would cause the machine to pause and wait for more data to come in.

[Rich Harman]

... I found that it totally ignores a very slight slant until I make steep enough for the stepper to add about 10 clicks spanning the approx. 2.4"... Until then, no clicks at all.

Your machine is pausing 10 times to make the line??? Or are you just observing how the Y axis stepper is advancing but the laser is moving smoothly during the line?

[Keith Winter]

They must be referring to the type of memory where you can download the entire job to the machine then run it independently of a computer. The machine itself absolutely must have some memory to store the incoming information and then put it to use. The incoming serial data would be stored, error checked, then sent on to some other memory location to be processed by the controller. When it is no longer of use it would be flushed to free up space for more data. The amount of data required to cut a single straight line is so small that I could not believe that it would cause the machine to pause and wait for more data to come in.

Rich and Lee I believe you. However I've been round and round with tech support and they continually deny any ram or memory of any sort. Never try to use logic with tech support is what I've learned. ;)

As for the OP curious about my other questions and if heat has anything to do with it?

[Lee DeRaud]

Rich and Lee I believe you. However I've been round and round with tech support and they continually deny any ram of any sort. Never try to use logic with tech support is what I've learned. ;)

As for the OP curious about my other questions and if hear has anything to do with it?There may not be anything on the circuit board readily identifiable (or, more to the point, replaceable) as "RAM".

But implementing a FIFO of the required size on an FPGA is trivially simple, and a FIFO is still "memory" by pretty much any definition.

[Gene Jameson]

ok I have dived a little deeper into this issue and I have spent way more time on it than a sane person should. but now it is personal. This is long and tedious but I thought I would share what I have figured out.

If you saw the video you know the issue is the pause in the middle of the last segment. Several on here have talked about the x, y servos needing this pause to accocunt for such slight movement in one of the axes. I really have problems with this explanation because we have a cnc router here that has no trouble doing simultaneous x and y movement with out missing a beat. And this is basically the explanation given by epilog. I just don't like it. Others talked about the possibility of slow down because of a lack of communication speed between the computer and the laser. I have a Universal Laser that requires the computer to be on to run a job. The Epilog machines only require the computer to send the job. Once the job is sent to the laser, the computer can be turned off and the job still runs fine. So I don't think it is an issue that involves computer power at all. So I did some more testing and this is what I found:

Test 1: I reran the problem part just like in the video to make sure it runs the part the same way with the same pause. It ran just like before with the pause in the center of the last segment.
Test 2: I drew a single hairline the same length as the one that has the pause. Sent it to the laser and it ran straight across with no hesitation.

after this is decided to double check the coordinates of the endpoints of the original line to make sure it is purely on one axis. It was. But I did notice two nodes within a few thousandths of each end point of that line segment. I felt stupid that I had not noticed these nodes before, but I re-sent the job to the laser (Test 3) and the hesitation was still there. I was kinda glad that did not fix the problem.

Next, I re-examined the line and right clicked on it and noticed the option "to line" was not grayed out and "to curve" was grayed out. This meant the segment was a curve. I had not noticed it because the adjustment arrows were so straight and I was usually too zoomed in to see the ends of them. Now I felt really stupid and changed the segment "to line". Of course, I re-sent (test 4) the job to the laser and it cut straight across with no hesitation ($#!t). The two end points of the line had been on the same y coordinate but the center or apex of that curved segment was 0.002 above that coordinate. This seems to prove the notion of such a small incremental change in the y axis causes the hesitation. This stinks, because I just don't think it needs to be this way.

Then I took the straight line segment I created in step two and added a node in the middle and ran the job (test 5). it ran without hesitation, so I know just adding the node did not create a hesitation. For test 6 I converted the segments on each side of the new node "to curves" and I nudged the center node up 0.002 to create the same geometry of the original part with one exception. it now has a node in the center. Sent it to the laser and ran it. The laser hesitated 2 times on this segment, at the center of each half of the line. This test just added further support to the encoder incremental change explanation.

For one last test, test 7, I simply double clicked on the center node to delete it. The curvature of the segment remained and I sent the job to the laser again. This time it ran the whole segment without hesitation. I don't get it. I was stating to buy into explanation that the encoder is a linear encoder that is attached to the axis. Compared to our CNC router where the encoders are on the servos themselves giving a greater density of encoder positions per linear movement of the axis. But the last test proves that is not necessarily the case. At least I can begin to use nodes and curves/lines to fix it when it happens.

[Lee DeRaud]

Next, I re-examined the line and right clicked on it and noticed the option "to line" was not grayed out and "to curve" was grayed out. This meant the segment was a curve. I had not noticed it because the adjustment arrows were so straight and I was usually too zoomed in to see the ends of them. Now I felt really stupid and changed the segment "to line". Of course, I re-sent (test 4) the job to the laser and it cut straight across with no hesitation ($#!t). The two end points of the line had been on the same y coordinate but the center or apex of that curved segment was 0.002 above that coordinate. This seems to prove the notion of such a small incremental change in the y axis causes the hesitation. This stinks, because I just don't think it needs to be this way.

Then I took the straight line segment I created in step two and added a node in the middle and ran the job (test 5). it ran without hesitation, so I know just adding the node did not create a hesitation. For test 6 I converted the segments on each side of the new node "to curves" and I nudged the center node up 0.002 to create the same geometry of the original part with one exception. it now has a node in the center. Sent it to the laser and ran it. The laser hesitated 2 times on this segment, at the center of each half of the line. This test just added further support to the encoder incremental change explanation.

For one last test, test 7, I simply double clicked on the center node to delete it. The curvature of the segment remained and I sent the job to the laser again. This time it ran the whole segment without hesitation. I don't get it. I was stating to buy into explanation that the encoder is a linear encoder that is attached to the axis. Compared to our CNC router where the encoders are on the servos themselves giving a greater density of encoder positions per linear movement of the axis. But the last test proves that is not necessarily the case. At least I can begin to use nodes and curves/lines to fix it when it happens.[raw random speculation follows...]
The common factor in the "failed" cuts seems to be that the curve consists of two separate Bezier segments, one with control points at the start node, the other with control points at the end node. My suspicion is that the firmware gets to the end of the first segment and then has to compute all the points on the other segment (working back from the far end) to figure out where to go next. Hence the pause. This theory has the advantage that it has nothing to do with the physical motion system, which, as you noted in your last test, can handle the actual motion involved without any problem.

It might be instructive, assuming it's possible, to look at the actual job as transmitted to the machine. It appears the Epilog is working at a higher level than ULS (and presumably Trotec), decomposing curves to line segments at the laser end rather than the computer end, minimizing storage space but thus having to deal with more extensive math at burn-time. My ULS works similarly to Kev's description in post #11, except that the low-level 'plot' components are formatted (more or less) as WMF rather than HPGL. (As I recall, WMF has arc and ellipse primitives, but the ULS spool files don't use them, converting everything to straight line segments.) All the vector reordering and optimization is done in the print driver as well.

[Rich Harman]

ok I have dived a little deeper into this issue and I have spent way more time on it than a sane person should. but now it is personal. This is long and tedious but I thought I would share what I have figured out...

Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

[Keith Winter]

Nothing's perfect.. I've even seen a Trotec pause maybe once or two waiting on transmission but the computer was bogged down opening a massive file. It was a split second but enough to make you think wth? That's one or two times in three years though, pretty darn rare and nothing like he's experiencing. We also experience other transmission errors from time to time such as a section of a design line being off by 1/2 or 1/4th of a millimeter when engraving. Not a lot, but enough to ruin a design. Happens maybe once in a blue moon but it does happen...


Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

[Gene Jameson]

Thank you for diving into the issue and reporting your findings, including your own errors. :-)

Not sure how to put this without offending, but it is disappointing to me that a mainstream (expensive) laser would have such a silly problem. The only time my laser has ever paused during a line is when cutting circles at a too-fast speed. And that pause is a fraction of the length as the one you experienced. It would pause for like a tenth of a second while it adjusted for backlash at each quadrant. When cutting at reasonable speeds, no pausing is perceptible.

I wonder if you were to smart fill the original graphic, then use that to cut the shape, would it still do the pausing?

I agree, it is not a huge deal but it is silly and I find the inconsistency to be annoying. My ULS 60 watt never shows any of these issues. While I am working at trying to troubleshoot problems like this the Universal is working it a$$ of and not complaining. I do find the epilog machines to be more robust in their construction, but it is hard to beat the ULS in my shop. But i am getting off topic and I am sure that can of worms has been opened many times.