my x-laser mobile beat mirage and etherdream2 ...

Ok. Somethin weird is goin on that i don't understand.
So i'm hopin' you guys can point out what dumb ass thing i'm doin...

my weird c++ goes...
it should be pretty easy to see how it maps to EtherDream.dll.
I flipped the usual order to EDWriteFrame with pps and reps.
so example below is 1000 pps and 1 rep.
Oh and f is just an increasing unsigned long with frame#.

void Framer::FRAME (ulong f)           // DA GUTS !!

{ ubyte c;

  ulong i, w, x;

   Dac [0].rMin = (uword)_c->r.Get ();   Dac [0].gMin = (uword)_c->g.Get ();

                                         Dac [0].bMin = (uword)_c->b.Get ();

   i = f % 64;

   c = (ubyte)i;   w = 65536 - (255-i)*255;   x = (65536 - w) / 2;

DBG("FRAME `d r=`d g=`d b=`d", f, Dac [0].rMin, Dac [0].gMin, Dac [0].bMin);

   ED.Dot (0, 0,0,0, x,     x);

   ED.Dot (0, 1,1,1, x+w-1, x);

   ED.Dot (0, 1,1,1, x+w-1, x+w-1);

   ED.Dot (0, 1,1,1, x,     x+w-1);

   ED.Dot (0, 1,1,1, x,     x);

DBG("putBgn");

   ED.Put (0, 1, 1000);  // plenty slow pps

DBG("putEnd");

}

What I really don't GET is why my green is SO FAINT on the laser.
minimum value to get a red is 1568. same for blue. green min is 1536.

Any red or blue AT ALL completely drown out green at it's max (32767).
And green even at 32767 at max is noooot very bright running this code.
I'd think this code would have huge lags at the dots.

I juuuuust dooooon't geeeet itt.

I'm sure my code is broke somewhere.
But it sure SEEMS like the green laser in this thing is not working properly.
argh.

oops.  and...



   void Dot (ubyte d,  ubyte r,ubyte g,ubyte b,  ulong x,ulong y)

   // r,g,b are balanced

   // x,y in 0-65535 as usual coords where y incr down.

   { EDCfg *c = & _cfg [d];

     EDPnt *p = & c->pt [c->npt++];

     uword  xr, xg, xb;

      xr = xg = xb = 0;

      if (r)  xr = (uword)(c->rMin + (ulong)(c->rMax-c->rMin) * (r-1) / 254);

      if (g)  xg = (uword)(c->gMin + (ulong)(c->gMax-c->gMin) * (g-1) / 254);

      if (b)  xb = (uword)(c->bMin + (ulong)(c->bMax-c->bMin) * (b-1) / 254);

      p->r = xr;

      p->g = xg;   if (xg > xr)  xr = xg;

      p->b = xb;   if (xb > xr)  xr = xb;

      p->i = xr;

      p->x = (sword)( (c->xFlip ? (65535-x) : x) - 32768 );

      p->y = (sword)( (c->yFlip ? y : (65535-y)) - 32768 );

      p->al = p->ar = 0;

DBG("pt[`d]  x=`d y=`d r=`d g=`d b=`d i=`d",

c->npt-1, p->x, p->y, p->r, p->g, p->b, p->i);

   }





   void Put (ubyte d, uword rep = 1, uword pps = 30000)

   {  if (! _dll)  return;

      while (Busy (d))  ::Sleep (2);

     EDCfg *c = & _cfg [d];

      EDWriteFrame (& c->dac, c->pt, c->npt*sizeof (EDPnt), pps, rep);

      Clr (d);

   }

gives this debugging...

00003001 8:00:38.430 PM 11932 FRAME 373 r=1500 g=32767 b=1500
00003002 8:00:38.430 PM 11932 pt[0] x=-7013 y=7012 r=0 g=0 b=0 i=0
00003003 8:00:38.430 PM 11932 pt[1] x=7012 y=7012 r=1500 g=32767 b=1500 i=32767
00003004 8:00:38.431 PM 11932 pt[2] x=7012 y=-7013 r=1500 g=32767 b=1500 i=32767
00003005 8:00:38.431 PM 11932 pt[3] x=-7013 y=-7013 r=1500 g=32767 b=1500 i=32767
00003006 8:00:38.431 PM 11932 pt[4] x=-7013 y=7012 r=1500 g=32767 b=1500 i=32767
00003007 8:00:38.431 PM 11932 putBgn
00003008 8:00:38.682 PM 11932 putEnd
00003009 8:00:38.682 PM 11932 FRAME 374 r=1500 g=32767 b=1500
00003010 8:00:38.682 PM 11932 pt[0] x=-7141 y=7140 r=0 g=0 b=0 i=0
00003011 8:00:38.682 PM 11932 pt[1] x=7139 y=7140 r=1500 g=32767 b=1500 i=32767
00003012 8:00:38.682 PM 11932 pt[2] x=7139 y=-7140 r=1500 g=32767 b=1500 i=32767
00003013 8:00:38.682 PM 11932 pt[3] x=-7141 y=-7140 r=1500 g=32767 b=1500 i=32767
00003014 8:00:38.682 PM 11932 pt[4] x=-7141 y=7140 r=1500 g=32767 b=1500 i=32767
00003015 8:00:38.682 PM 11932 putBgn
00003016 8:00:38.937 PM 11932 putEnd
00003017 8:00:38.937 PM 11932 FRAME 375 r=1500 g=32767 b=1500
00003018 8:00:38.937 PM 11932 pt[0] x=-7268 y=7267 r=0 g=0 b=0 i=0
00003019 8:00:38.937 PM 11932 pt[1] x=7267 y=7267 r=1500 g=32767 b=1500 i=32767
00003020 8:00:38.938 PM 11932 pt[2] x=7267 y=-7268 r=1500 g=32767 b=1500 i=32767
00003021 8:00:38.938 PM 11932 pt[3] x=-7268 y=-7268 r=1500 g=32767 b=1500 i=32767
00003022 8:00:38.938 PM 11932 pt[4] x=-7268 y=7267 r=1500 g=32767 b=1500 i=32767
00003023 8:00:38.938 PM 11932 putBgn
00003024 8:00:39.192 PM 11932 putEnd


So you can see from the timing that EDWriteFrame is not all that fast...
Like 1/4 a sec sometimes - pretty slow...
Does that sound normal ??

First. ED2 color values are 0-65535 natively. If you use the EzAud interface then 32767 should be ok for max but i am not sure for the native interface. Check into that.

Is it EDWriteFrame that is causing the slowdown or is it the loop where you check for the DAC not to be busy?

well i've got some BAD news :(

I guess x-laser doesn't quality control their lasers very well cuz the green diode just barely puts anything out !!

I also emailed the sales dude 2 weeks ago and no response.

I emailed him again 2 days ago and got an out of office that they're at NAMM or somethin.

So I emailed the main tech support email yesterday and I guess they don't work on weekends !!

ARGH.

I know it ain't just my code cuz red and blue behave just fine.
AND the demo that boots when the laser ain't connected to ILDA has very weak green.
VERY weak. Like just barely visible.

SO THAT SUUUUUCKS !!

And it does look like the delay is in the busy check.
Maybe I'll try skipping it and see what happens.
But i'm pretty sure i saw code that checks busy WITHIN EDWriteFrame that will just exit if busy.
But yep, often a full 1/4 a second waiting for busy to go away.

I must be overloading the dac with frames or somethin.

So do i just gotta not be constantly sending frames or somethin?

I'll try sending a repeating frame, too. That'll at least cause less traffic.

sigh.

Sorry about the laser. I'm sure you'll get it sorted out eventually.

I think there is a mimimum of 30 pts per frame or something like that for ED. Try increasing pts to see if that has any effect.

a minimum number of points? weird. why would there be a minimum?

well, i'll definitely give it a shot. and try repeat > 1. and give the dll/EtherDream2 some time to breath.

thanks for the suggestions. i'm gonna just keeeep trying stuff till somethin works :)

i'll eventually get it.

i HAD it on a 33 millisecond period timer wakeup.
But frame generation took too long cuz of that wait on busy to go away thing.

So i put it back to "just keep sendin frames in a tight loop".

So I'll just have to increase the period and try things till frame generation takes under 33 msec.

Minimum points might be because the overhead of sending one point at a time makes it slower then the single point can be processed.

I'll be experimenting with frame size and repeat today. We'll see how that affects timings.


So nowww i need to study point optimization.
I guess in general, you set pps to max your laser will do (30000 for mine).
Then you add extra drawn/undrawn points to give the scanner more time to get there.
Cuz that 30,000 assumes the beam is ONLY going 8 degrees max, right?

So the length of the drawn(or undrawn) line needs to be taken into account.

And when the beam cranks to a new angle, you may need dwell points at
the vertex depending on the angle between the 2 lines.

Anybody got any good docs on the technical aspects of doing this?

I'm guessing I'll need to calc the length of each segment, and angles between segments.
Then use those 2 values to add dwell points to give the servos multiples of the 30,000 pps (=1/30,000 of a sec) to truly "get there" before hitting the new beam color or off value and wrecking stuff cuz it ain't there yet.

I've found... http://www.art-science.org/journal/v...-v7n4pp155.pdf

Anybody got more docs?

Thanks much :) I'm over the funk of having to return my laser now at least.

I can make do with just red and blue and dream of greeeeen. that almost rhymes ha ha.

Yeahhhhhhhhhh it was that dang Sleep (2) ... SHEESH !!

2/60 of a sec is 1/30 of a sec which is the full time amount i've GOT to generate a frame...

I'll have to do a busy wait or use a higher precision timer to wake up.

Soooo i'm back on track again.

Sleep(2) is unlikely to sleep for 2ms. More than likely it will be around 8ms because of the minimum timeslice that Windows will actually sleep. You can measure it with a performance counter. In my code I just do a hard loop to wait for the DAC to become non-busy and it seems OK. Not optimal but I dont have a better solution at the moment.

i'm pretty sure Sleep(60) is for a second. So 2 is for a full 1/30 of a sec !!
That is way the frick too long for frame generation.

I'm resorting to a busy loop at the moment.
But my midi sequencer and sound synthesizer will be running at the same time...
So I'll eventually make a millisec timer for my laser code so it can ACTUALLY sleep for say around 10 msec.
Instead of 333 msec !!


I'm back on track in that department at least !!


So now I'm a gonna bug you about pps.

When they say 30000 pps at 8 degrees... Does that meeeean...

my aperture being 45 degrees and there being 65536 points in width,height...

That I can get by withOUT putting dots between segments that are
approx 65536 * 8 / 45 dots long ?

And use the 65536*8/45 value to figure out how many points I'll need to put between far away points in a long line?

Or is that assuming too much?

Thanks John. It's nice to know someone who has already treaded these here waters.

...Steve

Quote:

---

Originally Posted by stephenhazel

i'm pretty sure Sleep(60) is for a second. So 2 is for a full 1/30 of a sec !!
That is way the frick too long for frame generation.

I'm resorting to a busy loop at the moment.
But my midi sequencer and sound synthesizer will be running at the same time...
So I'll eventually make a millisec timer for my laser code so it can ACTUALLY sleep for say around 10 msec.
Instead of 333 msec !!


I'm back on track in that department at least !!


So now I'm a gonna bug you about pps.

When they say 30000 pps at 8 degrees... Does that meeeean...

my aperture being 45 degrees and there being 65536 points in width,height...

That I can get by withOUT putting dots between segments that are
approx 65536 * 8 / 45 dots long ?

And use the 65536*8/45 value to figure out how many points I'll need to put between far away points in a long line?

Or is that assuming too much?

Thanks John. It's nice to know someone who has already treaded these here waters.

...Steve

---

Sleep() takes ms as a parameter but it isn't accurate. Depends on when Windows decides to yield. 8 is about the lowest you can go. There is a lot of online documentation about it.

30000 at 8 degrees refers to galvo tuning using the ILDA test pattern. If you aren't displaying the ILDA test pattern it means nothing. I can scan 1000000000000000 pts per second if they are all in the same place. As a rule of thumb, you can use around 1000 as a max distance between pts. But, it depends on scan speed. There is no substitute for playing around with speeds, point spacing, angles, and dwell points.

Yep. You're right about Sleep() being in msec.
And when i changed it to a busy wait, WAY more responsive.
Which is weird, but then, windows sigh...

Ohhhh only for the ilda test pattern... So it's really mooostly a marketing spec i guess.

So i got me some rotating shrinking triangles that are about 1/4 max size.
It draws 4 of the triangles per frame in a continuous loop.

I'll setup my 24 frame/sec timer pretty soon.

It is really interesting to see the intertia in the scanners.
I guess there's NO getting away from intermediate points a pausing based on the angle.
Cuz otherwise those scanners will be all over the fricken place.

It is super cool to see them at max speed. They can't draw crap, but it's cool to see the clarity even if they can't reach the dang points ha ha.


Wellllllllll, i guess i better get to experimenting some more.

Some progress at least.

Buuuuuut tomo i gotta mail it in :(
When x-laser gets my mail notification thing, they mail me the replacement.

Hooooopefully I'm back in business by Friday sigh.

Quote:

---

When they say 30000 pps at 8 degrees... Does that meeeean...

---

This is a tuning optimization parameter guideline for the ILDA test pattern.

Try as a rule of thumb for point intervals in straight line segments one point every 4% of 65536 for even brightness along the line. There may be better algorithms for this. On delay, dwell or wait points between vertexes, 2-3 dwell points for short distances and 5-7 dwell points for long distances, before the beam is turned on, then have an "ON" dwell for 2-3 points, as a start. Lots will depend on your scanner's closed-loop frequency response.

Another good way to get a feel for this is to create a square, box image at maximum size, with 5 "OFF" dwell points and 2 "ON" dwell points at each vertex. Then fill in between the vertexes with additional single point values, e.g. 4 fill points, 8, 16, 32, etc. and look at each variation over a range of pps.

I really liked the article you posted from the art-science journal. In the past, we just did the point-route and dwell calculations in our head as we drew out the image outline on a digitizing tablet. Sure is nice to have horsepower to do it on the computer from a scanned image file.

Thanks yet again dude !!

Those specs are GREAT starting points - much appreciated :)))