Help - Left edge of photo on marble is blurry

[Peter Zacarelli]

This is my first attempt to laser photos with a solid background on marble with my new VLS3.50 50 watt.
Problem is the photos fade away as the laser nears the left edge (see pic).
I have tried printing from Corel and 1-Touch Laser Photo with the same results.
Is my laser out of focus or out of alignment? I just cant figure this out.
Any information, comments, or help would be greatly appreciated.

Thanks,
Peter

[Mike Null]

This is likely due to the ramp up/down in power as the laser nears the left edge. Try moving you drawing away from you left ruler by about an inch to see if that is the problem.

[Peter Zacarelli]

This is likely due to the ramp up/down in power as the laser nears the left edge. Try moving you drawing away from you left ruler by about an inch to see if that is the problem.

Mike, I moved it over like you said and it worked fine.
However I would like to know what the actual problem is, you said it was due to the ramp up/down in power can I compensate for this? It is a new laser.
Is this normal for lasers to have this problem? I will make a jig for this but I really would like to know if there is something with the laser itself that I can fix and or adjust.

Thanks again for your help Mike

[Scott Shepherd]

It's normal. Most lasers today don't engrave to the edge of their travel. Seems stupid to me, but I'm not building them. You'd think if someone built a table that was 12" x 24", and material is sold commonly 12" x 24", then you'd make the machine fit the material, but they don't. You'll need to stay off the edge if you want graphics to run to the edge.

What's an extra inch of travel in the X Axis cost in parts? $20? Can't be much more than that to have the shafts,parts, etc. just be cut 1 inch longer so you could have the full range of travel at 100% speed.

[Robert Walters]

Are we talking the the motion or the laser ramping up/down near the edge?

[Dan Hintz]

Robert,

Both... as the motion ramps up/down, the laser needs to do the same to keep consistent power per distance. So far, most laser manufacturers can't seem to get it right in that regard.

In some cases, this can be attributed to out of alignment lenses/carriages, but in this case I agree, it's the driver.

[Scott Shepherd]

Who's Walter? :D

[Dan Hintz]

Fixed... NO idea what I was doing to read that as Walter :(

[Lee DeRaud]

What's an extra inch of travel in the X Axis cost in parts? $20? Can't be much more than that to have the shafts,parts, etc. just be cut 1 inch longer so you could have the full range of travel at 100% speed.Well, leaving aside the extra cost (note that it affacts everything, including the case), if you did make the thing wider, people would be wondering why they can't cut to the limits of the carraige travel. I suppose you could make the working area different size depending on whether you're rastering or vectoring...oh wait, that's how it works now.

[Robert Walters]

Well, leaving aside the extra cost (note that it affacts everything, including the case), if you did make the thing wider, people would be wondering why they can't cut to the limits of the carraige travel. I suppose you could make the working area different size depending on whether you're rastering or vectoring...oh wait, that's how it works now.


Humor/sarcasm aside...

If you pay for 12x24 working area, I'd expect to be able to use that.

The rules/guides are there for a reason, if I have to start shifting everything over by an inch when I have 100 pieces with tight tolerances to get out, I don't want to have to deal with if I got the blank aligned in the machine properly.

(Yes, I could make a 1" spacer, but that's not the point =)

With as long as Universal has been around, you would think they could get the kinetics adjusted properly.


Peter,

Do you have the latest firmware installed by chance?

[Scott Shepherd]

When I was at a show about a year or so ago, looking at the Trotec, the guy was doing a demo where it was engraving at 100% speed, all the way to the edge of the work. They were bragging about how their machine was the only one in the market that would engrave edge to edge at 100% speed with no loss of quality on the edges. It was done, quite simply, by just making the engraving area smaller than the travel by the required amount.

[Joe De Medeiros]

I haven't seen this effect, does it only happen when you are running at 100% speed?

[Robert Walters]

It was done, quite simply, by just making the engraving area smaller than the travel by the required amount.

Well, aint that a steamy pile of bovine poo!

I haven't seen this effect on mine, but I haven't had a chance to really dive in yet either. Something I'll keep an eye out for.

[Gary Hair]

It was done, quite simply, by just making the engraving area smaller than the travel by the required amount.

On my GCC the "normal" size of the bed is 32" x 20" but I can extend it to 38" but I sacrifice some quality on both ends. I have used it at that length many times to cut sandblast resist and it vectors just fine. I haven't rastered close to the ends so I can't say how well it works although I'd guess it wouldn't be too terrible.

To get the full width I have to remove a 3" wide guide ruler on the left side, that's how they keep you in the "sweet spot" of the ramp up/down zone.

Gary

[Peter Zacarelli]

Humor/sarcasm aside...

If you pay for 12x24 working area, I'd expect to be able to use that.

The rules/guides are there for a reason, if I have to start shifting everything over by an inch when I have 100 pieces with tight tolerances to get out, I don't want to have to deal with if I got the blank aligned in the machine properly.

(Yes, I could make a 1" spacer, but that's not the point =)

With as long as Universal has been around, you would think they could get the kinetics adjusted properly.


Peter,

Do you have the latest firmware installed by chance?


Robert,
First, I have Firmware v5.0, I believe this is the latest perhaps you or someone else knows for sure.

Second, I agreed with you 100%. I cannot for the life of me figure out why they cannot compensate for this through the software. In my opinion if you paid for a 12" X 24" table then you should be able to use a 12" x 24" table or else it should be stated in the user manual you can not use the first inch or perhaps maybe the driver should not let you raster the first inch or should automatically reduce the speed. Since the mechanics of this machine are completely software driven by a dedicated computer one would think that the software (driver) would be able to compensate for this. Like you said Robert it is about tight tolerances and this issue just adds another layer to checking and double checking. Perhaps the issue is just beyond the engineering of these machines, I don't know but I am glad my cheap inexpensive photo printer prints borderless with out a problem ever - maybe the laser manufacturers should take some lessons from Epson or HP?

I will make this statement about the lasers that I have worked with or have seen working in the field and it is this, the mechanics (hardware) seem pretty solid but gees when it comes to the software they just can't get it right and are light years behind. My Control Panel is flaky, bugging and annoying to say the least. I find this problem exists in a few different markets. If there are any medical people out there or diabetics then you will know what I am talking about. Take blood glucose monitors for example, they are a marvel on to themselves but the software they use to save and report the information on some machines is a nightmare. But then you look at the medical robots or even industrial robots they have to work flawless time and time again. It seems that in some fields they either can not get good software engineers or do not want to pay enough for good software or it would just be to cost prohibitive. My two cents anyway :)

On a positive note, it is really nice to see people that are willing to take their time and effort to post on these boards with answers, solutions and thoughts. I for one am very thankful and appreciate that you people are around to lend a helping hand and give your advise.

Peter

[Bill Cunningham]

I've never had that problem! I just did a 8x10 granite photo, with a .375 solid border all around. I move the artwork over and down the width of a hairline (too small to be noticed, and just off the corel table area edge) and laser away.. Perfect border, right to the edges.. I have also vector cut right up the left edge and across the top without problems. My area is 12 x 24 minus a hairline

[Robert Walters]

Robert,
First, I have Firmware v5.0, I believe this is the latest perhaps you or someone else knows for sure.

Second, I agreed with you 100%. I cannot for the life of me figure out why they cannot compensate for this through the software.

Call or email universal and ask them the latest version of FIRMWARE, not just driver or software.

Kinetics shouldn't be in software imo, that should be a firmware issue as it needs to be a REAL TIME thing, not a virtual driver one.

But I'm getting a bit off track here.

[Dan Hintz]

Kinetics shouldn't be in software imo, that should be a firmware issue as it needs to be a REAL TIME thing, not a virtual driver one.
Considering for all late-model ULS machines the firmware and driver are practically the same thing, that's a sticky wicket. I agree with you, in principal, but when the line is blurred as ULS has done, well...

[Robert Walters]

Considering for all late-model ULS machines the firmware and driver are practically the same thing

I knew the smaller ULS desktop units required a dedicated PC, I didn't realize that *ALL* their models required a dedicated PC now - that is just *SO* wrong.

When you run a job, do you see the CPU spike for the whole job, or do you think they're using an FPGA and the like?

[Robert Walters]

Robert,
First, I have Firmware v5.0, I believe this is the latest perhaps you or someone else knows for sure.

I see version 5.28.52.2 as of 2010-06-08




Second, I agreed with you 100%. I cannot for the life of me figure out why they cannot compensate for this through the software...Well, that's the problem actually... ULS went a cost saving route in requiring a dedicated PC to offload the workload to, instead of an internal dedicated hardware controller as I understand it.

Old hardware developers took pride in their work, software developers now just shove garbage out as the higher ups are pushing the deadline for a release (much of the mentality is "we'll get it right next time, just get it out the door now").

Under MS-DOS (a real time OS) it was simple to create a "Hello World!":


#include <iostream>
using namespace std;
void main()
{
cout << "Hello World!" << endl;
}Under Window (a virtual OS), to do the same thing (circa 1990) is cumbersome:



#include <windows.h>

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);


/* WinMain(), our entry point */

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
LPSTR szCmdLine, int iCmdShow) {
static char szAppName[] = "winhello";
HWND hwnd;
MSG msg;
WNDCLASSEX wndclass;


/* Fill in WNDCLASSEX struct members */

wndclass.cbSize = sizeof(wndclass);
wndclass.style = CS_HREDRAW | CS_VREDRAW;
wndclass.lpfnWndProc = WndProc;
wndclass.cbClsExtra = 0;
wndclass.cbWndExtra = 0;
wndclass.hInstance = hInstance;
wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
wndclass.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
wndclass.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
wndclass.lpszClassName = szAppName;
wndclass.lpszMenuName = NULL;


/* Register a new window class with Windows */

RegisterClassEx(&wndclass);


/* Create a window based on our new class */

hwnd = CreateWindow(szAppName, "Hello, world!",
WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT,
CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInstance, NULL);


/* Show and update our window */

ShowWindow(hwnd, iCmdShow);
UpdateWindow(hwnd);


/* Retrieve and process messages until we get WM_QUIT */

while ( GetMessage(&msg, NULL, 0, 0) ) {
TranslateMessage(&msg); /* for certain keyboard messages */
DispatchMessage(&msg); /* send message to WndProc */
}


/* Exit with status specified in WM_QUIT message */

return msg.wParam;
}


/* Window procedure */

LRESULT CALLBACK WndProc(HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) {
PAINTSTRUCT ps;
HDC hdc;


/* Switch according to what type of message we have received */

switch ( iMsg ) {
case WM_PAINT:

/* We receive WM_PAINT every time window is updated */

hdc = BeginPaint(hwnd, &ps);
TextOut(hdc, 100, 100, "Hello, world!", 13);
EndPaint(hwnd, &ps);
return 0;

case WM_DESTROY:

/* Window has been destroyed, so exit cleanly */

PostQuitMessage(0);
return 0;
}


/* Send any messages we don't handle to default window procedure */

return DefWindowProc(hwnd, iMsg, wParam, lParam);
}
Code monkeys are cheap, hardware/firmware guys are not.

[Dan Hintz]

Old hardware developers took pride in their work, software developers now just shove garbage out as the higher ups are pushing the deadline for a release (much of the mentality is "we'll get it right next time, just get it out the door now").
It's not that we don't take pride in our work like hardware guys, it's that we don't have a choice. As long as we want a paycheck, we'll have to deal with such nonsense. Oh, and the hardware guys don't have it any easier...

Code monkeys are cheap, hardware/firmware guys are not.
Good code monkeys are not cheap, and they shouldn't be... but hardware guys (FPGA, especially) typically command 10-15% more for the same experience level. Which is amusing when you think about it as FPGA programming is, for the most part, C programming these days (and even back in the days of straight VHDL).

[Robert Walters]

It's not that we don't take pride in our work like hardware guys, it's that we don't have a choice.

I do understand it's the higher ups pushing for releases. It is sad though that they can develop easter eggs with such elegance, yet can't do the same for the boring project code.


Which is amusing when you think about it as FPGA programming is, for the most part, C programming these days

Sure, but it aint GUI. No fricken frameworks (gawd I hate that term). At least with FPGA you have a blank slate to work off of and the worse thing you have to worry about is if you have enough gates to add that last little subroutine :D

[Scott Shepherd]

I don't consider having a dedicated PC a "flaw". I really like the way ULS handles that side of things. Having job control software is very important for me and without the computer set up like it is, I doubt I could have that. I also like the fact that I don't get stuck with outdated firmware that's buried on a machine. Every time there is an update, my system is exactly the same as one that's rolling off the factory floor, 3 years later.

I would never go back to a print it and send it type set up.

Also, I have a rotary engraver that has a dedicated computer, I have a CNC router that has a dedicated computer. So this isn't something new to ULS, it's been happening for a long time by a lot of people.

Bill, it will vector to the edge fine, it's just at high speed rastering and you said you move 3/8" from the edge, that's probably enough on your machine to skip over the issue. Try rastering at 100% all the way to X0 or X24.

[Mike Null]

My old ULS did not use a dedicated pc. How long have they been doing this?

Currently, all my equipment is run from one pc. Laser, Rotary and 3 printers.

[Scott Shepherd]

3 or 4 years.

[Lee DeRaud]

My old ULS did not use a dedicated pc. How long have they been doing this?

Currently, all my equipment is run from one pc. Laser, Rotary and 3 printers."Dedicated PC" is somewhat of a misnomer in this context: a PC driving a ULS laser can have any number of other devices attached to it. The computer is only dedicated in the sense that there has to be a direct USB connection to the laser.

What you can't do with a ULS machine is share it as a printer over the network. I'm not convinced that really qualifies as a bug.

[Lee DeRaud]

Sure, but it aint GUI. No fricken frameworks (gawd I hate that term).We'll continue this discussion after you explain exactly what GUIs and application frameworks have to do with device driver development.
(Hint: the correct answer is "zero, zip, nil, nada".)

[Richard Rumancik]

Well, . . . if you did make the thing wider, people would be wondering why they can't cut to the limits of the carraige travel. I suppose you could make the working area different size depending on whether you're rastering or vectoring...oh wait, that's how it works now.


Lee has it 100% right.

When I got my Mercury, with a 25" x 18" table, I realized that the carriage could actually move outside the specified table width used when it was rastering, due to the necessary overtravel. So it seemed to me that GCC was wasting table space for people who wanted to vector cut wide sheets. There was .75" or 1" overtravel on each end (I can't remember remember exactly) but let's say 1". That would mean you could vector cut 27" instead of 25" wide IF ONLY the software would allow it to. But it won't, so the way I looked at it, I have a 27" table and can only use 25" for vectoring BECAUSE they set the limit at 25" in firmware, since that is the rastering limit. That seemed wrong, and I told them so. (Don't think they heard though.) I felt that if I was vectoring only I should be able to use the full addressable area of the table.

Fast forward to 2010 and GCC has since released units that do just that. So have the other companies. (Except Trotec, it seems, who is selling an old-style table calling it a feature.)

NOW people complain that since they can vector to the edge, why should they not be able to raster to the edge? . . . . sigh . . .

It's not that complicated to offset your part in 1" for rastering. Shouldn't be that hard to find a 1" strip of acrylic in a laser shop.