newb alert. help me into this laser code writin' stuff please...

[stephenhazel]

Please don't do that. A 400mW standing beam is still plenty powerful and capable of lighting cigarettes, especially using tight single mode diodes.

Really? Wow. Ok well I'll be careful. I'm gonna have to google what "single mode diode" means.
I know the hardware that generates the beam is called a diode.
I know a diode in electronics keeps the electricity flowing one way.
And I guess it's like that but with light.

But I'm not sure what the "single mode" part means.
I know it's analog tho! Cuz i want colors

Thanks for the .I info John !! Very helpful.
I bet it's just for old school lasers that couldn't do RGB and used to determine if the beam should be on.
Maybe even for lasers that have an analog diode but of only one color.

OK TIME TO CODE ))

[araugh]

The short version, single mode diodes produce very tight, sharp beams, not to be underestimated. No one ever got hurt by being too safe.

[stephenhazel]

I'll be careful. I like my eyes !!

Ok, I've got a pretty definitive answer on the .I intensity biz.
Searching the firmware code of EtherDream, I find it can load ilda files off the SD card if they exist.
Even ILDA data stored in .WAV files - weeeird.
And it has a SetIntensity() function that sets the .I member to the MAX of .R,.G,.B which makes sense.
That way it'll only be 0 if aaaall of the R,G,B components are 0.
Which should make the ye olden lasers happy.

I found out that structure member padding is not my issue. It's the same size packed and regular.
(16 bytes = 8 members * 2 bytes - x,y are signed 16 bit, r,g,b,i,al,ar are unsigned 16 bit)
Packed or not - same # bytes.

But white (r g and b all being the same at whatever power level) does NOT look white...
It looks magenta-ish. When I set them seperately, red and blue and green show up the right color.
Red seems a little brighter, but that might be just cuz it's red.
So I don't know why I can't get white yet...

I also am getting 0 back from EtherDreamGetNumDAC() when I open the EtherDream lib the 2nd+ time...
I thiiiink I'm shutting down correctly.
EDStop (dac#); EDCloseDevice (dac#); to close my DAC
then EDClose () to shut down the whole EtherDream dll process. (I think?)

So I'll need to experiment with my shutdown code so I can use the dang thing a 2nd time without rebooting the dang dac...

Hmmmmmm. HARDWARE !! Why can't it be like software.
Actually, it's probably the software I'm fighting...

...Steve

[lasermaster1977]

Thanks for the .I info John !! Very helpful.
I bet it's just for old school lasers that couldn't do RGB and used to determine if the beam should be on.

Color, Intensity and Blanking - ILDA
The following rules are defined so that color usage on separate-blanking and color-blanking systems is consistent.
All writing programs MUST write bit 14 of the Status Code. This blanking bit is a 0 if laser is on (draw) and a 1 if laser is off (blanked).
For separate-blanking systems, then this bit simply reflects the blanking status. For color-blanking systems, then this bit MUST be 0 if any of the
RGB values is greater than 0, and MUST be a 1 if the RGB values are all 0. If a system does not use 8-bit color resolution, the color resolution MUST
be mapped onto 8 bits.

For example, if a system has 2-bit resolution (four different color levels), the level is multiplied to fit full scale 0-225. Two-bit “0” remains 8-bit “0”, 2-bit
“2” becomes “85”, “2” becomes “170” and “3” becomes “255”.

Even if a system does not use any color or blanking, it is suggested to write a Color Table Header. For compatibility with the proposed ILDA
Standard Color Palette, specify just two colors in the table — Color 0 with RGB values of 0, and Color 1 with RGB values of 255 — and write all
points using Color 1.


My former reference to another "I" was for color indexing alluding to the different type and data format codes within an ILDA image header section where there can be coordinates with indexed colors (where the value is an index into one of eight color palette tables) or coordinates with true colors (RGB 0-255).

[stephenhazel]

hmmm. those specs sound like they're for ILDA output by the DAC.

Cuz the EtherDream.dll API (which i guess mostly follows the EasyAudioDAC API)
only has .x/y/r/g/b/i/al/ar. x and y are signed 16 bit, the rest are unsigned 16 bit.
and it SEEMS like r/g/b/i range from 0 to 32767 and they get <<1'd in the driver
then sent to the DAC. Why? I dunno. Just tryna make it work.

[lasermaster1977]

hmmm. those specs sound like they're for ILDA output by the DAC.

Cuz the EtherDream.dll API (which i guess mostly follows the EasyAudioDAC API)
only has .x/y/r/g/b/i/al/ar. x and y are signed 16 bit, the rest are unsigned 16 bit.
and it SEEMS like r/g/b/i range from 0 to 32767 and they get <<1'd in the driver
then sent to the DAC. Why? I dunno. Just tryna make it work.

Yup, they are. I'm assuming EtherDream's API follows to an extent the ILDA standards for compatibility. Me, I'm just now trying to wrap my head around C++ programming and just loaded the MSVS Community IDE. So you know far, far more about what the EtherDream API's look like than me, that's for sure.

[stephenhazel]

I'm not very thrilled with MSVC. c++ used to be a lot less messy.
I only use c++ cuz i started back in the dark ages and c was THE language.
And i took the c++ path instead of java. aaaaanyways...

So i ACTUALLY reached j4cbo (Jacob Potter) on IRC. Mr. EtherDream.

Told him about GetNumDACs returning 0 after a successful session of open/writeframe/stop/closedevice/close.

Sent him 2 logs to look at. We'll see what he says.

I was worried that he'd moved on to other projects and left this one in the dust - whew !!

So there's that and my white color problem still.
I'm wondering if it's due to the point being so focused. Maybe if it's scanning longer lines it'll look
more white or something.

So tomorrow I finally draw the big rectangle with different colors and see where I get.
(big rectangle being the max frame the laser will do)

...Steve

[lasermaster1977]

I'm not very thrilled with MSVC. c++ used to be a lot less messy.
I only use c++ cuz i started back in the dark ages and c was THE language.
And i took the c++ path instead of java. aaaaanyways...

So i ACTUALLY reached j4cbo (Jacob Potter) on IRC. Mr. EtherDream.

Told him about GetNumDACs returning 0 after a successful session of open/writeframe/stop/closedevice/close.

Sent him 2 logs to look at. We'll see what he says.

I was worried that he'd moved on to other projects and left this one in the dust - whew !!

So there's that and my white color problem still.
I'm wondering if it's due to the point being so focused. Maybe if it's scanning longer lines it'll look
more white or something.

So tomorrow I finally draw the big rectangle with different colors and see where I get.
(big rectangle being the max frame the laser will do)

...Steve

I started in Assembly Language for the 6502 processor family many decades ago, that I still understand. I too, had about a year of C co-developing code for a mail sort machine. But I've slept since then ;-), I have none of that code to review and reference anymore making it a new learning curve.

The issue with your white color problem has to do with the fact that the output powers of each RGB diode is not the same. As you mentioned your red diode is the brightest, and often this is the case, and the reason for the reddish-white results. Therefore, there is the necessity to adjust color balance (and in some cases intensity linearity from dimmest to brightest) between RGB diodes to yield white. Today's software capabilities makes this possible to incorporate. I am sure this is done by determining the max 8-bit value of R's intensity that yields a closer white balance given GB's maximum of 255. Then, the max for G or B may need further tweaking as well. The tweak on all three (RGB) brightness values should yield the best white and when the same is done on the opposite end for dimness for each color should yield the best white fade up/down linearity.

Maybe I can get some C++ pointers from you from time to time.

[stephenhazel]

Hey thanks LaserMaster1977 !

So i gotta balance em myself, eh. I've been spoiled by display adapters I guess

My lineage is c=pet(basic) > zx81(z80 asm) > c=64(6502 asm) > Amiga500(c,c++,68000) > MSDOS(c,c++,80x86,pascal,fortran) > windows*(same). I've played with Android java. Hate Apple.
I don't use asm any more. All my home stuff is c++ on win32 api.
My work stuff is the oooole website junk(php,oracle,etc)

So I'll try to bury the color balancing and point optimizations in my driver-ish code that sends the frame.

That way my graphics code (kinda top level, app-ish code) can just write a bunch of lines with r,g,b
similar to what you'ld put on a regular lcd with the windows gui api.

Thaaaaaat's the plan at least. Hopefully all the point optimizations won't be toooo tough.
2nd+ off point at end of a "pen up" line. measure the angle between to "pen down" lines and
give a delay at the bend based on the angle.

We shall seee how it goes. I'd be happy to help ya out with c++ any way ya need.

...Steve

[lasermaster1977]

Hey thanks LaserMaster1977 !

No problem. Going over this stuff again helps me as well. I see you've been at this a while!

I finally got MSVS 2015 installed !! (already had 2017 when I first loaded the EtherDream project files and it barked at me about not having the 2015 stuff). Opened the Etherdream.vcxproj file and now I can see what you've been referencing, Steve. And oh yeah, #Include files, that rings a bell.