what exaaaaactly does 30000 pps mean...?

i know it's a speed for how fast your galvos can move.

i know it stands for pixels per second.

i'm slowly coming to terms with point optimization so your galvos aren't spending all their time just freaking out - maximum segment length, dwell and stuff.

Buuut 30000 pps... what EXACTLY is meant by a pixel? EtherDream coordinates are usually in the range of 0..65535 (or -12768..12767, whatever) for x and y.

But I am pretty dang sure my laser doing 30000pps will take WAY less than a second to draw a line along one of borders (32768 pixels, right??)

So what exactly is a "pixel" in pps ?

And is there any GOOD SOLID fully formed docs on point optimization so my dang squares quit lookin like circles?
i (also) get that you wanna split super long lines up into a maximum segment length. I got the trig for that done. I get there should be multiple points at the and of a line so the galvo can stabilize. But not so many that the point outshines the line...

But I really could use some help with that optimization stuff. Any links round here you guys got?

Thanks muchooo.

...Steve

30000pps means NOTHING.

Projector with 30000pps @ ILDA 8Deg which is something like a Standart means he can scan the ILDA 30K Testpicture with 30000 Points per Second.

But also if a Chinese Projektor is sold with 30Kpps ( Kilo Points per Second) this dont need to be the truth :-)


The ILDA Testpattern are availible for free but it is important to scan them as they are. No additional Interpolation, Corner Repeat or what ever….

https://www.ilda.com/resources/Stand...n95_rev002.pdf

Quote:

---

Originally Posted by Guido

30000pps means NOTHING.

---

Hrm. Ok, that part is comin' back to me.

But you DO send pps to the DAC. And it is doing SOMEthing with that dang number.

So what does it mean to the DAC? Does it simply pass it along to the galvo firmware that kinda takes whatever the max your projector is rated as and slows down the galvos X percent or somethin ?

Is there any good way to TRULY test your laser's galvo speed?
Like put up a plain old border rectangle and count the millisecs for the frame to complete?

Hrm.

Hi,

to compara Galvos please use the ILDA Testpattern like linked above.


The DAC is sending "X" Points per Second the Galvo Driver Circuit which send Current through Galvo´s Coils to reach the wished Position.

But if the Galvo is too slow the next Point from the DAC is comming before this Position is reached. So the Output dont look as expected.


The ILDA Testpattern is exactly what you Need to get the true Galvospeed measured at a defined Angle.
Start with 15kpps. In the middle of the Figure you see a blue Circuit outside the Square. No increase Scanspeed. The Blue Circle gets smaller and smaller.

When he is exactly inside the Square and still round you can say "My Galvos can do XX Kpps @ILDA 8 Degree" . When the Blue Circle is an oval the Scanspeed ( Combination of Gain/Damping of Driver, adjustable by Resistors )
isnt equal. But when you never adjust Galvodrivers by yourself dont try: Normally the Result after the first Try is bader than before :-)


Hope you understand what i was writing.. my Motherlanguage is German :-)

I'm thinking of it as a low pass filter, the slower the galvos the lower the cutoff frequency. If you try and draw a square too fast, corners get clipped as the signal is clipped and so the filter has prevented the galvos from ever defining a sharp corner. Even though it's a DC signal to the galvo amps, any sort of output is going to have an AC frequency that generates that pattern. The mass of the galvos combined with the electrical impedance of the coils combined with the maximum available current sets the max speed of the set.

You don't send PPS to a DAC, you send an analog AC signal. If the frequency of the analog signal (scan speed) is higher than the bandwidth of the galvo set you get round corners! The only thing can be done is slowing down the scan speed, sending a slower frequency that allows the galvos time to dwell and reach the commanded position. Course you can always reduce the scan angle. As I understand this will lower the DAC output frequency and magnitude to something the scan set can handle, assuming the frame is just a simple square.

Also, in case anyone else more experienced is here can confirm for me, a circle drawn at full frame width should be a perfect sine wave on the X and Y signals? At 30KPPS, you'd expect the sine wave to be ~30KHz, at 20KPPS 20KHz? If you leave all else the same, a circle drawn at half frame width, 30KPPS, would be 15KHz input signals?

You can also tune galvo sets, since galvos have position sensors they know if they are in the desired position or not. If they aren't, the tuning settings configure the maximum allowable current to drive those galvos into position. These settings need to stay set for a defined scan speed and output frame size, or scan angle. Tuning a galvo set isn't something a newbie needs to be taking on, so it would be best for you to try displaying ilda test frame at multiple scan speeds and angles untill you find where that circle just touches the square. Keep scanning at those speeds and angles, and your squares should stay square. Good luck!!

What nobody seems to understand is the circle in the square in the ILDA TEST PATTERN measures the approximate "3 dB Down" point of the galvo frequency response at a specified test condition.
~
The test pattern is a unit of measurement set up so artists who are non-techies and techies who are non-artists can get a figure of merit both sides agree on for a given galvo pair under standard conditions.
It gives us a common reference to interchange vector artwork and to tune the galvo servo loops, without needing a table top full of test gear. . 30Kpps is roughly a 2.4 KHz galvo response bandwidth for very short jumps. As that bandwidth available changes with angle, decreasing with larger jumps, the angle of the standard test pattern projection is specified and the sample rate for its reconstruction is specified.
~
There is no easy formula to convert KPPS to a galvo frequency response , because the equation approximating the motion of the galvo under closed loop control is a very complex polynomial.

1/KPPS (ie..the reciprocal) is the time in seconds between DAC output updates.

~
KPPS in terms of the DAC and Software is the update rate per point in the image without any image optimization or vector processing applied. Then you can assume the galvo acts as a complex, non-linear low pass filter with a integrated memory of its last positions and some resonances if driven out of its ballistic response region. There are whole books on Galvo dynamics, it is not an easy subject to understand.
~
Closed Loop Galvos have a frequency response of DC to low audio.
~
Steve

well i DEFINITELY appreciate the responses.

All i send to the dac in a frame is a list of x,y,r,g,b.
All i send with the frame is reps and pps.

IS IT TRUE that the DAC takes that pps of 30,000 and goes...

OK! My ONE job is to send these x,y,r,g,b things to the laser ONE at a time in analog.
So every 1/30000 of a second I'm gonna pop a new x,y,r,g,b in analog voltages onto my output wires.

That -absolutely- means that every 1/30 of a millisec, a new pixel is given to the galvo circuitry.

Which means that for a given frame, I can NOT adjust that duration per pixel. All pixels are sent at the SAME speed.
And the only way to adjust the speed is sending the SAME pixel more than once for multiples of that duration OR
to split lines into shorter lines by adding points in between.

So if things are nice for me, the galvos ARE at the last point and stable. Say at top left corner.
And I want those galvos to go to, say, the bottom right corner.
1/30 of a millisec is probably not long enough to get there? and the galvos will be freakin when they DO get there.
But I kinda need to know that max speed.
Then I kinda need to know a minimum and maximum "freak recovery" speed.
minimum will be if the next dot is in the direction we were already going.
maximum will be if the next dot is the opposite direction (or maybe 45 degrees off opposite?)

Couldn't those 3 parameters get you what you need as far as optimizations with
points between and dwell point repetition?

I understand we wanna get the artists and the techies talking. But that test pattern...
It's not sinking in for me...

Missing Basic, when you do a Jump in one Step from upper left to lower Right and repeats this several Time your Galvos will answer with Smoke..
The Galvodriver is designed for fast , small Steps..such big Jumps need to be interpolated.
In case of direction Change ( a.e. at Square´s Corner ) you need to add angle depending Point Repeats and so on...

Here is a layman's description of "pps" which could stand for "pixels-per-second" or "points-per-second". A picture pixel or point has a precise location described on an X (horizontal) and Y (vertical) grid system. In theory and practice the grid system could be 256 "X" columns by 256 "Y" rows (256,256) or higher multiples such as 512,512 or 1024,1024 or 32768,32768.

Remember the connect-the-dot pictures we did a kids. Each dot had a number from 1 to 50 or 80 or more. Each dot had a precise location (X,Y coordinate) on the page, although what they were did not matter is this example. The picture revealed itself when all the dots were connected starting at dot "1" connecting it with a pen or pencil to "2" then "3" then "4". The closer the dots were together the faster you could draw a line between them and the further apart adjacent dots were the longer it took you to draw a line between them.

If you timed yourself on how long it took you to draw a line segment, in numeric sequence, from start to finish this would be described as your drawing at "50 dots-per-minute" for example. So dots=points=pixels of a picture or image.

A laser picture or image is comprised is just the same way as the connect-the-dot pictures, where each point or pixel has a "numbered position" in the image (being the 1st point, 2nd point, 3rd point, etc. until the last point of the image) except that the laser image also has additional color information for each pixel or point as well. The pixel or point of the image is defined by its X coordinate value and its Y coordinate value. But what determines how fast a laser image can be drawn is dependent on a number of factors.

When laser imaging software is "spitting" out an image to the laser XY galvanometers or scanners it is send each point's XY number value to the X and Y DAC in rapid succession until it reaches the end of the image then it repeats the image until instructed to display a new image or stop. And of course the X DAC takes the digital X number and converts it to a proportional X signal voltage to send to the X galvo amp that drives the X mirror to a new position that deflects the laser beam moving in a similar fashion, and ditto for the Y DAC.

1. How many total points there are in the image
2. How close and/or how far away each adjacent point is from each other
3. How quickly the laser XY galvos can respond to changing voltage values

The cheaper the XY galvos are the slower they tend to be. 20-pps do not cost near as much as 40 or 60 pps galvos.

The speed at which a computer can spit out the image XY values to the DACs and the XY mirror deflecting galvos is far, far faster than the galvos can respond, so the are ways of making sure the computer software sends the XY point sequence of an image at speeds the frequency the galvos are capable of following accurately such that the images shape stay true to what it is supposed to look like.

Like mixedgas said, the ILDA test pattern visually helps show whether the galvos are setup correctly or are capable of rendering the ILDA image accurately speed and size-wise.

ok.

But is it true that if pps is 30000 that THIS MEANS that
the DAC delivers the analog x,y,r,g,b to the laser for exactly 1/30 millisec before giving it the next point?

Quote:

---

Originally Posted by stephenhazel

ok.

But is it true that if pps is 30000 that THIS MEANS that
the DAC delivers the analog x,y,r,g,b to the laser for exactly 1/30 millisec before giving it the next point?

---

In the ideal world, yes. But as mixedgas stated (and I alluded to) 30K pps is a sustainable rate IF the succession of adjacent points are very close together, but not when they are far apart and the jump between two points is a long one. It all depends on how the image's points are "put together". So think of it as a generality.

well, the DAC will definitely send the x,y,r,g,b for that duration (1/30 of a millisec).

But whether the galvos actually reach the next point (and aren't all freaked from the LAST point)
depends on optimizing the line segment length and dup dots so the galvos actually make it to the dot properly.

I mean, I've not found many links about optimizing those dots properly.

Has it historically just been done manually i guess?

It is also possible to use a DAC with a fixed clock set to 48KHz, aka a sound card.

It's all a matter of how the vector art is converted into something that can be properly scanned.

LaserBoy has extensive optimization functions that can be applied individually to a frame or frame set. So you can see what each one does. You can also do all of the optimization techniques at once. You can set values in LaserBoy value settings that control every aspect of how LaserBoy optimizes your vector frames and save the results in any format of ILDA. You can also save a frame set as a LaserBoy Formatted Wave file that can be played through a modified sound card to produce the (analog) signals.

Optimization is more of an art than a hard science. I figured out how to do it in a way that works. It's in my open source code.

James.

ahhhhh yes. LaserBoy.

Your code is definitely on my "to read" list, James :)

But, i mean, i've taken a first look around aaaaaaaand... ummm... Your code is long, dude !

I have NOT given up. I will figure it out yet !
But it's not gonna be a snap i don't think, heheh.
I do appreciate the open source biz tho. That's pretty cool.

Quote:

---

Originally Posted by stephenhazel

well, the DAC will definitely send the x,y,r,g,b for that duration (1/30 of a millisec).

But whether the galvos actually reach the next point (and aren't all freaked from the LAST point)
depends on optimizing the line segment length and dup dots so the galvos actually make it to the dot properly.

I mean, I've not found many links about optimizing those dots properly.

Has it historically just been done manually i guess?

---

Being an 'ol fart from ye ol' days, we just learned through trial and error how many "wait XY points" had to added to give the galvos time to catch up to that point to maintain the shape or to make sure the beam OFF or ON code wasn't too late or early. It didn't take long before it was 2nd nature to know how many duplicate XY points to add based on the distance between points to maintain the shape or make the beam blanking timing just right. I mean we had to do it manually because the computers we used didn't have the computing power to calculate this on the fly.

Well, you can certainly look at the code as it is now, but I've been grinding on it pretty much every day since the last release. I've fixed so much stuff it's like a version 2.0.

The basic idea is the core memory model. It's all based on the C++ STL container class vector <template>. I wrote all the classes and figured out how to do all the math that makes it all work. Everything it does is in the code. The only thing libSDL does for me is give me the address of the first pixel of the display window and tell me what key just got hit in any OS.

That's why there is so much code. A fairly large part of it is the text menu system!

I'm always glad to answer questions about any of it.

If you're really interested you can PM me for a daily build of the exe and a current copy of the code.

Well I'm glad i got you guys.

Some background on me - my main app is pianocheetah - a weird midi sequencer.

Once a year, my neighbors have "Hogmanay". That's what they call new years in Scottland.
One of us grew up there. We have it Feb 23 in between Christmas and Spring when nobody
is doin NOTHin. It involves kind of what it involves in Scottland - a lot of drinking, going to peoples' houses.

We carry around a huge paper mache herring so that people really know we can party.
Even at our age.

Anyways, its 4 weeks away so I gotta show off my laser. At least I'm almost to the point of
rifling thru ilda files to the beat of some dang midi files i find.
Eventually it'll tie in to the music a LOT better. But i only got 4 weeks.

Last year the theme was LASER OLYMPICS.
All i managed to do was some rotating shrinking triangles, random dots, random lines, and
other kiiiiiinda boring stuff. Lots of distortion going onto my ceiling.
Oh and the olympic rings.
I did get the optimising pretttttty ok. But imperfect.
I set off the smoke alarms in my house and a LOT of drunk people got VERY annoyed ha ha.

So things can only be better this year. We'll see how it goes.

The reason i wanna write this stuff is cuz i can.
And so it'll tie into my midi sequencer. soooome day.

Ok. Glad I'm on the right track.

Thanks yall.

What is your programming language of choice?

i find myself a dinosaur. but i'm on windows10 using c++ and win32 api.

i am totally frustrated with what microsoft and it's os have turned into.
but i won't go mac (too elitist). So that leaves me linux and chromeos.

i mean, chromeos is linux. but it's linux supported by google...

and you just can NOT do a proper user interface in win32 anymore.
people have been spoiled by css on the web.
so since the web has taken over almost all front ends...
eventually, once webassembly fulfills it's promise, i'll try to cram my whole midi sequencer on the web.

the chrome webmidi api ain't perfect, but it does actually work...

And i bet there's a sockets api that could get my etherdream hooked up...

i dunno. window10 is probably gonna be eaten by chrome os for the average home user.
Then the web will be all we have and all the APIs that google jams into chrome.

I dunno. I like to pontificate. But so far i'm still stuck dealin with microsofts slow slow death.

I don't want apple to win. and i want chrome os to go faster.

Well, I've been around for a while too. I learned C and C++ in 95 and 96. I was immediately attracted to Linux because those languages are native to UNIX like operating systems. They do exist in Windows, but they can't really do everything they were designed to do, mostly because of the differences in file IO.

When I first started on LaserBoy I wrote the whole thing. I even wrote all of the code that directly communicates with the video card. The only thing I didn't write was the Linux kernel and the GCC compiler!

I think MS Windows has really gone down hill. Windows 10 just plain sucks. It's HUGE, bloated and eats resources for no real benefit. The best version of Windows ever put out there was 2000. That was almost 20 years ago! I don't know what MS will do to stay relevant. I think most people will drift away from MS and not even notice it. People will probably move toward Android.

Quote:

---

Originally Posted by james

Well, I've been around for a while too. I learned C and C++ in 95 and 96. ...
People will probably move toward Android.

---

Well i think we kinda think alike.

I've written my own MFC basically on top of win32. But I'm also a web dev at work.
I used to be a back end perl and oracle guy.
Then i got a new job and my boss forced me into web front end.
I mean, it is super convoluted. But you can make a web front end a hell of a lot prettier than a win32 app.

I think microsoft has just locked up win32. no one is allowed in. you can only write stuff on top.
None of the control panel programs use caching any more. You see the stupid spinning dots everywhere.
There are duplicate UIs everywhere. It's just a mess.

So you think Android, eh? I used to think that too.
But I just got a chromebox, a chromebit, and a chromebook. (overkill, but i don't care)
If you're willing to write a web app in javascript, you can do a LOT of stuff with modern browser APIs.
Angular seems pretty cool for a framework. I'm starting to learn that so i can free myself from php.

So I kinda think chrome os will take off more than android.
It boots in 7 seconds into a chrome browser. But underneath is Linux.
And you can install a Linux container. It is protected from the main linux os of chrome os.
For security reasons i guess? Those things also run android apps.
They run great with 4 gigs of RAM and chrome screams compared to win10.

From what I read, google is working on a new os called Fuchsia.
It's supposed to replace both android and chrome os.
I have my doubts about it tho. It's not based on linux. some realtime os called Zircon - wtf??
And chrome os is getting a lot of market share.
Stores are selling it and people are buying it.
No viruscheckers cuz it's built in. Updates happen niiiicely.
And chrome os is Linux. Patched and supported by google.
I hooked my chromebox to my hubs and it recognized ALLLLLL my midi devices, not to
mentions screens, keyboards, mice, etc. No drivers like windows would need.

Anyways, I've messed with linux servers, but chromeos is my first personal/front end-ish pc.

Which flavor of Linux do you use?

And what GUI api do you use on Linux then? I've always been curious about that.

In the old days we called them blanking points, guide points, and corner points. If you had a long dark jump between lit points, you added blanked points to guide the galvos so they landed smoothly at the net lit section. If you had a lit segment between two distant points you ADDED guide points that were lit. If you have a right angle turn you added a few points at the vertex of the corner to give the galvo time to de-accelerate , a typical setting in Pangolin for 30K galvos is to automatically add 3 or 4 corner points. We used to do that BY HAND, and distorted the image by "Pulling Points" by hand to fit a given set of Galvos. The ILDA test pattern and modern software ended that.
~
Oh, Some Galvo Math, Or "Why I just love the ILDA test Pattern and Learned to Live with the Bomb". (parody of famous movie script)
~
http://www.academia.edu/6503978/Opti...turing_Systems
~
I can tune my galvos for peak performance using Bode plots by injecting square waves and measuring the galvo response in the time domain. Perhaps less then 0.5 % of Galvo owners for laser shows have the equipment and training to do this. Hence the concept of the ILDA test pattern and the KPPS measurement. Guido knows how to do this too. He and I would agree that it is an engineering exercise requiring considerable skill. So the ILDA pattern is a nice compromise.
~
To do it the old way, You'd need a way of understanding Bode Plots and PID loops before tuning, and that requires some electronics and physics education or you incinerate your galvos during tuning.
~
Hence the ILDA pattern and tuning methodology. Some really skilled people worked this out, but since the process was NOT well documented, so many people are skeptical about what they DON'T understand. Generally they don't have access to professional show software, nor the oscilloscope and waveform generator to sweep the galvo amp at small signal state and make measurements. (Not recommended for Galvo Beginners anyways)
~
Mr. Hazel, Drop me an email and I'll send you a very clear academic paper on the difference between point oriented graphics and vector optimized graphics.. I'll forward it to James so he can guide you in the software. I cant post it here, copyright... Your DAC uses point mode, but the paper should help you get some of the concepts. James does some similar things in Laserboy...
~
Ah, never mind, found it for free:
~
see: https://core.ac.uk/download/pdf/144248935.pdf

see: https://www.art-science.org/journal/...-v7n4pp155.pdf for a start..
~
If you understand high order math:
~
https://link.springer.com/article/10...e.jors.2601161
~
Products like Pangolin products, Lasergraph Dsp, and LSX handle this automatically for you.

~
~
Steve

I really don't care about what distribution Linux is. It's all about the kernel. I used Red Hat for many years, but now I'm using Ubuntu.

Ubuntu has a huge user community and if you need to know how to do something or to find an app it's all out there.

I've done tons of web development using my own C++ CGI API. I also wrote ezfb that is a nice little API for the Linux Frame Buffer (video card) in C.

I don't have much experience with GUI APIs, but if I had to pick one to use I would probably go with FLTK. Anything I would want to do should be something that can compile in any OS.

I have to get LaserBoy ready for a new release soon. It does so much more stuff now! The new version has even more stuff that no other laser app can do (that's in addition to all of the stuff it does now that no other laser app can do!)

Quite honestly, my favorite place to be on a computer is in a BASH shell at the command prompt. If I'm using ssh into a far away machine, that's ok too.

Quote:

---

Originally Posted by mixedgas

I can tune my galvos for peak performance using Bode plots by injecting square waves and measuring the galvo response in the time domain.
Steve

---

Steve, wow, what a blast from the past, Laplace Transforms, Bode plots, poles and zeros. I hadn't thought about or used those in years. Thanks for the memories and the article references.

Quote:

---

Originally Posted by mixedgas

In the old days we called them blanking points, guide points, and corner points. ...
~
Steve

---

Holy smokes Steve / gaslight that is some goooooooooood STUFF !!

I will be a readin'...
But although i can algebra with the best of em... Higher math is kiiiiinda hard fer mee.
I learned about PID in my son's high school robotics. It's also pretty dang calculus-y if i remember.

I do get the jist of the pid stuff, but not all the way down...:(

So I'll do me some readin. Thank you so much, dude !

Your name, by the way... Excellent choice by your folks. (I guess you can tell i'm a dad now)

Quote:

---

Originally Posted by james

I really don't care about what distribution Linux is....
Quite honestly, my favorite place to be on a computer is in a BASH shell at the command prompt.

---

I love this plaaaace. I wish i could have a beer with all yall.

Sooo, you gotta web front end on a linux os with a CGI thing that hits your laser's audio-ish DAC thingyyy ?

So is there a laserboy.app that does this stuff?

I like the linux prompt way better than windows. that's for damn sure.
But I'm usually on windows mousin' windows explorer to kick my NEd (text editor).
Then wait a million years for visual studio to boot (and crash) and compile my dang cpp.

I'm not sure whether to go cgi-ish or webassembly. haven't tried either.


Do any of ya live anywhere near Seattle, WA ? Just curious.

LaserBoy comes with a pre-compiled 32-bit Windows exe.

It's built using MinGW, which is GNU GCC for Windows.

https://laserboy.org/forum/index.php...12582#msg12582

LaserBoy uses libSDL-1.2.15. It's a very well established cross-platform gaming API.

As I said, all I use it for is to give me a window in any OS and let me know the address of the first pixel of that display area. It also tells me what key just got hit.

When I first wrote LaserBoy, it only ran in Linux and the kernel had to be built with frame buffer support. I wrote ezfb, which is an API for the Linux frame buffer (video card RAM). So it ran in a Linux console, but it latched onto the video card and took over the whole display.

Someone on this forum, who is also a Linux user, told me about libSDL. I found out that it can also use the Linux frame buffer for display, but it can also open a window in all of the GUI operating systems out there too.

So that was a pretty easy switch.

I manage my own bitmap memory objects in my code. Everything you see in the LaserBoy display is a bitmap that I render in memory and copy to the display area every time you tap a key.

Just DL the LaserBoy_Current.zip in my signature line, unzip it at C:\LaserBoy\ and start using it in Windows.

James.

Quote:

---

Originally Posted by james

LaserBoy uses libSDL-1.2.15. It's a very well established cross-platform gaming API.

---

Ok. So your window just shows a bitmap and you draw eeeverything in it.
Interestin. Well, for now I'm probably stickin with ole win32.
In the future I'm gonna tryyy to get a web front end on toppa this stuff.
Weeeee'll see.

Quote:

---

Originally Posted by stephenhazel

Well I'm glad i got you guys.

Some background on me - my main app is pianocheetah - a weird midi sequencer.

Once a year, my neighbors have "Hogmanay". That's what they call new years in Scottland.
One of us grew up there. We have it Feb 23 in between Christmas and Spring when nobody
is doin NOTHin. It involves kind of what it involves in Scottland - a lot of drinking, going to peoples' houses.

We carry around a huge paper mache herring so that people really know we can party.
Even at our age.

Anyways, its 4 weeks away so I gotta show off my laser. At least I'm almost to the point of
rifling thru ilda files to the beat of some dang midi files i find.
Eventually it'll tie in to the music a LOT better. But i only got 4 weeks.

Last year the theme was LASER OLYMPICS.
All i managed to do was some rotating shrinking triangles, random dots, random lines, and
other kiiiiiinda boring stuff. Lots of distortion going onto my ceiling.
Oh and the olympic rings.
I did get the optimising pretttttty ok. But imperfect.
I set off the smoke alarms in my house and a LOT of drunk people got VERY annoyed ha ha.

So things can only be better this year. We'll see how it goes.

The reason i wanna write this stuff is cuz i can.
And so it'll tie into my midi sequencer. soooome day.

Ok. Glad I'm on the right track.

Thanks yall.

---

Spaghetti is C++/Win32/MFC. I avoid a lot of MFC, though. Microsoft exects everyone to use WPF for frontends for C++ apps I guess. WPF and Winforms will be coming to .net core 3.0 which will make it cross platform. Interesting, but I would still like a nice C++ UI toolkit. No one seems to care about that use case anymore. Professionally, I am working on a web app and it sucks trying to get decent performance out of a browser app. That's progress I guess.

Quote:

---

Originally Posted by stephenhazel

IS IT TRUE that the DAC takes that pps of 30,000 and goes...
OK! My ONE job is to send these x,y,r,g,b things to the laser ONE at a time in analog.
So every 1/30000 of a second I'm gonna pop a new x,y,r,g,b in analog voltages onto my output wires.
That -absolutely- means that every 1/30 of a millisec, a new pixel is given to the galvo circuitry.

---

If the DAC is operating in streaming mode (where it's not doing any optimization of the points in the frame itself), then yes, more or less, this is how it works. This is exactly how a sound card DAC works, with the caveat that you can run it at whatever output frequency you want (such as the 48KHz example that James mentioned).

However, in this case it is the *software* that must add points to an image to compensate for the large jump from corner to corner, to use your example. Some controllers (like the Pangolin QM-2000 board) have built-in optimization hardware on the card that can also add points as needed to limit the distance between points in a frame.

But either way, if you actually try to send the galvos from lock to lock in 1/30,000th of a second, they're not going to get anywhere close to their intended destination before you send the next point!

Quote:

---

I kinda need to know that max speed.
Then I kinda need to know a minimum and maximum "freak recovery" speed.

---

Yup. There's been a lot of research into this, even outside the laser industry, as galvos have been around for quite a long time. Also, some companies have a leg up simply because of their in-house experience. Example: Bill Benner over at Pangolin has done a ton of work with Cambridge to improve their scanners over the years, and of course now Pangolin produces their own scanners, so they have a great deal of real-world experience to draw from when designing these limits into their software. But if you're just starting out, you'll want to read what others have published about the limits of scanner response.

Quote:

---

that test pattern...
It's not sinking in for me...

---

See if this post helps. The last section describes what is going on with that center circle that just touches the square.

Quote:

---

Originally Posted by stephenhazel

I love this plaaaace. I wish i could have a beer with all yall.

---

Have you heard about SELEM yet? *retardo

Adam

There are a lot of laser show folks in Seattle. You just need to find them.

Steve

Quote:

---

Originally Posted by JohnYayas

Spaghetti is C++/Win32/MFC. I avoid a lot of MFC, though. Microsoft exects everyone to use WPF for frontends for C++ apps I guess. WPF and Winforms will be coming to .net core 3.0 which will make it cross platform. Interesting, but I would still like a nice C++ UI toolkit. No one seems to care about that use case anymore. Professionally, I am working on a web app and it sucks trying to get decent performance out of a browser app. That's progress I guess.

---

I'm not using mfc itself. I have some classes directly on top of win32 api that does just what mfc does but without the junkiness. All the classes jammed into an os.h and a ui.h


Yeah, browser != real time os...

webassembly seems almost ready for prime time? i guess?
But i dunno if it's gonna handle laser-y speeds...

But i think people are gonna get sick of os specific GUI apis... I know i am.
css gives you a lot more conSISTENT prettiness. But javascript gives you janky slopp.p...

Oh well. I should quit pontificating. And just do what works. That's what we dooo.

Quote:

---

Originally Posted by buffo

If the DAC is operating in streaming mode (where it's not doing any optimization of the points in the frame itself), then yes, more or less,

See if this post helps. The last section describes what is going on with that center circle that just touches the square.

...

Have you heard about SELEM yet? *retardo

Adam

---

Thanks dude! So the circle is 12 points where the galvos are freakin with intertia, eh?
(10 sided figure is 12 points? Wouldn't it be an 11 sided? But i get your point there)

That helps. But I'm still a little wobbly (ha! get it?). But I think I'm fine with wobbly.
My frames are lookin a lot better now.
Nowwwww my problem is dealin with logarithmic color sigh...


SE ??? I'm in NW... No faaaair...

Quote:

---

Originally Posted by stephenhazel

Thanks dude! So the circle is 12 points where the galvos are freakin with intertia, eh?

---

Yep. The points that make up the circle are all outside the square, and there are only 12 of them. (Well, technically there are 36 of them, since the laser makes 3 trips around the circle, but you get my drift.) And yes, during that time the scanners are "ballistic" - that is, they are under constant, maximum acceleration trying to overcome their own inertia. And the -3dB distortion that Steve was talking about above represents the difference in positional accuracy between the point's location on the frame (well outside the square) vs the laser's actual position just inside the square.

Quote:

---

(10 sided figure is 12 points? Wouldn't it be an 11 sided? But i get your point there)

---

It's 12 points, and 12 sides too, if you want to look at it that way. (Dodecagon.) And yeah, there is a typo in the post I linked you to. Just noticed it myself! I'll go fix that right now.

Quote:

---

Nowwwww my problem is dealin with logarithmic color sigh...

---

That's a whole 'nother can of worms. And even if you get it perfect (based on some theoretical standard, like the CIE color chart, for example) people will still tell you that you got it wrong, because color is subjective and *everyone* has their own opinion concerning the ideal color balance. And really, they're all valid. So don't kill yourself over it. Get it looking good to your eyes and call it a day. (Otherwise you risk your sanity...)

Quote:

---

SE ??? I'm in NW... No faaaair...

---

They have these things called "airplanes" now; perhaps you've heard of them? :D (Just messing with you!)

Seriously though, we have several people who fly in from the west coast to attend SELEM. A few of them have even driven by car! (Yeah, the event is really that good.) I know it's a long haul, but trust me, it's worth it. (Better yet, don't take my word for it... Just read the comments from other members about past SELEMs in the meet-and-greet sub-forum here on PL.)

Adam

Quote:

---

Originally Posted by buffo

That's a whole 'nother can of worms. And even if you get it perfect ... call it a day. (Otherwise you risk your sanity...)



They have these things called "airplanes" now; perhaps you've heard of them? :D (Just messing with you!)

---

Ha ha. Thanks Adam. Yeah i will look into that "airplane" biz but no promises.

I mean i think a logarithmic lookup is just like an x square-ish lookup table instead of an x times-ish table.



Hey i really only get hue with my color with lasers, right?
Ain't no black, right? I'd have to shine it on a black background and even then it ain't miiiixin w the background really...

And variations in intensity seem to be hard for myyyy eye to even notice much.

So mostly i try to get a hue and call it a day...