Page 4 of 9 FirstFirst 12345678 ... LastLast
Results 31 to 40 of 84

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

  1. #31
    Join Date
    Sep 2014
    Location
    Colorado USA
    Posts
    208

    Default

    Steve, you really need to review the ILDA data format standards here http://www.ilda.com/technical.htm.
    This should be quite helpful to you. Yes, ILDA standard is a 16-bit (2 bytes) signed Integer.

    The limit on how many points a frame may have is 65536. I really do not know what the lowest value for ILDA's pps is.

    I don't know what most people do who write display drivers but in my opinion why have any delay between frames at all unless needed as a "special effect".

    My preference would be to have a parameter that controls point-to-point delay which has the effect of controlling frame-rate and would range from "no delay" to some large value. And when optimizing the display accuracy of any image consideration must be taken for the lag speed inherent in the electro-mechanical, position feedback scanners. Let's say your software driver has the optimized capability to spit out 30,000 points-per-second over an 8 deg full-angle of scan area. Most likely the computer software and hardware can be far faster than this, but just as example you really want your scan angle to be 60 degrees full-angle, but your scanners can only keep up at 30,000 pps over 8 degrees of peak-to-peak deflection. If within your image of coordinate points you need the scan to deflect the beam from the 32767,-32767 coordinate (lower right hand corner, assuming front projection) then deflect to -32767, 32767 in the opposite diagonal over 60 degrees peak-to-peak, this cannot be done with just these two point values because the beam doesn't have time to get to the new point before it being told to go somewhere else. So there must be a variable inter-point delay before a new change in direction can be achieved accurately. The the bigger the point value deflection difference the more delay required between points. One way of doing this is to repeat the coordinate point in succession 3 to 6 times before outputting a new and different coordinate value to give the beam a change to reach its last target point. We used to refer to the consecutively repeated point values within an image "delay points" or "dwell points" since they compensated for the scanner reaction being far slower than the computer's ability to stream coordinate values to the DACs.

    The new schools guys can probably shed more light on this topic. (I'm an old fart)

    The plane of color you mentioned is nothing more than outputting a saw tooth wave for the X-axis (horizontal) that repeats about 30 times per second while outputting a sine wave on the Y-axis (vertical) that is "X" times faster than the horizontal signal. If X=1 then there will be one positive hump and one negative hump in the vertical plane e.g. one sine wave cycle. If X=8 then there will be 8 "sine waves" in the vertical plane. This is a good example of how the ratio of frequencies in the rate of what is happening in the X-axis compares with the rate of what is happening in the Y-axis. The type of waveform on the vertical axis determines the shape of the visual "waves". Use a triangle shaped waveform on the Y-axis and the waves have pointed peaks instead of rounded peaks.
    ________________________________
    Everything depends on everything else

  2. #32

    Default

    Hi lasermaster1977.

    Thanks for pointing out those specs. I'll read up.

    I figured there'd have to be dwell points or SOMEthing like that. servos can't keep up with software.

    Thanks for the explanations I think I'm gonna have a LOT of fun with this.
    Gonna just get it drawing a rectangle tomorrow. Then see all the colors I got and how thin the beams are.
    In the demo on the laser, I can already see that dots are a lot bigger than the lines between.

    I'll just start with simple stuff and see what happens when i make it dooo THIS !!

    And scratch my head and try to work out what the laser actually did

    This is the coolest thing I'll make the computer do since my midi sequencer

    ...Steve

  3. #33

    Default

    I like to think of the points as "control points" as in a Bezier curve. The DAC steps to the new analog values, and the scanner driver tries to keep up.
    I >think< one of the points of the ILDA test pattern is to confirm that the tuning of the galvo drivers is close to everyone else's tuning, so you can do tricks like making a circle from eight points. At the last SELEM, Bill showed a demo of the difference between the points and the actual output of a chicken -- it was pretty impressive.
    If you're going for 30 frames per second at 30000 points per second, you want to get as much as possible out of those 1000 points per frame.
    If you play the same frame at a lower points per second rate, the galvos will have more time to approach each control point and the points will brighten with dimmer lines between them. Brighter points look bigger, so it may be that your demo was intended to run faster than it is.

  4. #34

    Default

    ooo interesting.
    so the 8 points that would normally draw an octagon(septagon?) ACTUALLY draw a circle
    since the scanner path will probably usually be a curve unless the from and to points have same x or same y.

    so that pps stuff is pretty important.
    your frame rate is, too.
    cuz your scanners will usually be drawing curves unless given enough time.

    well, i'll see when i test it out.


    I kinda think for my OWN drawings, I'll stick with an x,y that are 0-65535 unsigned with y increasing towards bottom.
    That way my existing graphics functions can sooort of be used. I'm never thrilled with negative numbers.

  5. #35
    Join Date
    Nov 2006
    Location
    santa fe, nm
    Posts
    1,545,200

    Default

    Quote Originally Posted by DanBarlow View Post
    At the last SELEM, Bill showed a demo of the difference between the points and the actual output of a chicken -- it was pretty impressive.
    i don't know if this was autocorrect, a typo, or intentional, but it is the funniest thing i have seen today.
    suppose you're thinkin' about a plate o' shrimp. Suddenly someone'll say, like, plate, or shrimp, or plate o' shrimp out of the blue, no explanation. No point in lookin' for one, either. It's all part of a cosmic unconciousness.

  6. #36
    Join Date
    Mar 2010
    Location
    Raleigh, NC
    Posts
    1,971

    Default

    Quote Originally Posted by swamidog View Post
    i don't know if this was autocorrect, a typo, or intentional, but it is the funniest thing i have seen today.
    Not a typo. He was demoing their scanner simulator and showed that it even simulated pulled points accurately using one of PJs drawings. It was pretty impressive.

  7. #37
    Join Date
    Nov 2006
    Location
    santa fe, nm
    Posts
    1,545,200

    Default

    Quote Originally Posted by JohnYayas View Post
    Not a typo. He was demoing their scanner simulator and showed that it even simulated pulled points accurately using one of PJs drawings. It was pretty impressive.
    ohhhhh. right. now i know the context. the chicken thing was totally confusing me.
    suppose you're thinkin' about a plate o' shrimp. Suddenly someone'll say, like, plate, or shrimp, or plate o' shrimp out of the blue, no explanation. No point in lookin' for one, either. It's all part of a cosmic unconciousness.

  8. #38
    Join Date
    Sep 2014
    Location
    Colorado USA
    Posts
    208

    Default

    I'll stick with an x,y that are 0-65535 unsigned with y increasing towards bottom.
    I'm with you, Steve. I've always preferred my laser drawing world to be positive numbers back in the 8-bit days (0-255), in quadrant 1. But this was also because I reserved certain point values as special image codes. 0,0 was and End Of File code, 255,255 was a beam ON code, 255,0 was a beam OFF code and 255, (1-254) was an image speed code that determined the intra-point delay. At the end of each frame "pass" it would also check a command buffer to see if any new commands need to be executed, like "Draw" out the image, "Reverse" the image, "Invert" the image, "Scale" up/down the image, "Get" the keycode for the next image and display, draw, scale, etc that image.

    But, back then we wrote our binary driver software in Assembler to maximize efficiency of every computer processor's operation code execution cycles. But we had only 1 Mhz processor clocks. With today's computers that is no longer a big worry since processor clock speeds are so blazingly fast.

    These past many months I've been working on completing an ILDA conversion interface for my old single-DAC system, along with modifying the image driver to output RGB blanking (ON/OFF only) within an image and trying it out on a 3 Mhz system.
    ________________________________
    Everything depends on everything else

  9. #39

    Default

    ok my progress so far:

    rewrote netherdream.cpp and .h into an EthDrm class in a single .h file with functions to
    open dll
    get #dacs and assoc'd names (I'm pretty sure I'm stickin to ONE, but wth)
    open a dac
    see if dac is busy
    write a frame
    shut a dac
    shut dll

    And i've got the netherdream demo code into a .cpp file using that .h
    It compiles and EtherDream.dll is in the same dir as my laz.exe

    But I don't even get my first debug statement.
    So I'm pretty sure it's the virus scanner (avast or windows')

    I'll figure it out.

    I'm not sure how to go about my coords of 0..65535 for x and y. y increasing down.
    I thought about just flipping over the projector, but that'll flip x too and I only wanna flip y.

    I could just redo all the y's in my library code.
    But that'll stamp on them forever and I'm not sure I want THAT either.
    As the sending "app layer" code might not want to have to unmunge the ys.

    Ah well. Slow progress. But I'll git therez.

    ...Steve

  10. #40

    Default

    Oh and I did need to update the firmware on the EtherDream2.

    As I got it from x-laser, it's firmware software wasn't up to date.
    Sure is nice to be able to plop in on a usb to my pc and drag over the .fw file and BOOM DONE.

    That thing has some mighty nice LEDs, too. They even change colors and stuff.

    OK BACK TO DEBUGGIN.

    actually, back to makin' dinner before my gf gits herez

    ...Steve

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •