DeltaFlo

The MEGA has a different pin layout, so you need to use different pins (MOSI, SCLK) for the SPI connection to the DAC. * Arduino Uno/Nano pin 11 for Mega: 51 * Arduino Uno/Nano pin 13 for Mega: 52

You can‘t import jpeg directly. I provided a script that can translate gcode, which is used in laser cutting. To get the outline of an image, you need to convert it to a vector drawing and convert that lines to gcode or directly to my format (it requires programming). The hex format is just the x/y coordinate in 16bit and the first bit of X is used as a flag if the laser is on or off.

Hm, did you install the Teensy Addon for the Arduino IDE?And you need to select the Teensy as the target for building the code, since it uses Tennsy Libraries that re not available for Arduinos.

No, I don‘t. But it works like this: Connect the Sd to miso/mosi/clk as usual and connect the SD CS (chipselect) to a free digital pin on the Nano.Now take the SD reading example code and enable the SD CS while reading from the SD card but disable the MCP CS while doing so. Then, disable the SD CS and enable the MCP CS to draw what you have read.Alternatively, you could use a Teensy with two SPI ports or a Spark Photon which has a dual DAC built in (no mcp dac needed) so the SPI is free for the sd card.

Yes, the third ILDA pin is the GND.I think there are two power connectors on each board so that you can connect the power serially, which is why you only have one connection on the last board.

You are right, they are flipped, I think the schematic view is correct. But since the ILDA signal is bipolar (swings from -10 to 10v), this does not matter much (nothing will break), it will just flip the axis (which you can undo in the software)

Yes, just search for teensy and microphone.There is a discussion about this here:https://forum.pjrc.com/threads/32178-Connecting-a-microphone

Yes, that is possible. You only have to get the code running on it. You might need to increase the delays because the chip is so much faster.

No, you have to read the code and try to understand it. The current code only supports quads, but you can easily change that back to triangles, once you understande the code...

You can use the CS (chip select) of the MCP 4822 to enable/disable if it listens to the serial data. A SD card also has a CS, so you can use that as well, the SD card library allows you to specify the CS.So connect a spare digital pin to the mcp CS and set it to low when you want the mcp to listen and to high when you want to read from the sd.

I don't actually know the power of my laser pointer, since it was a merchandising gift. With a standard laser pointer, the room needs to be dark. If you use a more powerful laser pointer, it gets dangerous because you may not look into the laser anymore and you need protective glasses/gear.

That‘s correct, only two legs are connected.

I guess it is mainly the driver/feedback loop that tries to avoid over/undershooting. If you draw a rectangle, it is really hard to get the laser to point to the starting point exactly without drawing enough intermediate points and waiting at the edges. But if you use a better scanner/driver, the 16bit might make sense, if you want to invest the 50$.

Yes, that would work, but the chip is overpowered, since it has 4 channels and you only need 2. The evaluation board costs around 50$ and as I said, I don't think that 16bit will provide much over the 12bit, since the Galvos are not that precise.

You would need two DAC714 and use the "Cascaded Serial Bus Connection with Synchronous Update" to synchronize. I think that this DAC is too good for the galvos, you will not really see the 16 bit resolution compared to the 12 bit resolution. The advantage of the DAC714 is that it is already bipolar, so you could use it to generate a bi-polar output. The problem here is that the reference voltages that you need for the DAC714 are not directly available from the power source (since it only has -15 / + 15 V), so you would still need some voltage dividers to get the correct bipolar reference voltages.So I think you should just buy an MCP4822, it only costs 3-5 Euros.

That is correct. When you enter 0 you get -5V and +5V and when you enter 5V you get +5V and -5V. That is the idea of a bipolar signal that is transmitted redundantly.

Yes, that confirms my results... to get a sharp line ending/edge, one needs to wait for the mirror to fully stop, otherwise one gets an round edge or undesired trail at the end of a line.

That looks nice... Are you using your own methods for writing to the DAC?If I find some time I will incorporate the laser throttling into my source... You are right that it takes a lot of scan time if one waits for the toggling at the given position, so your solution is better, especially for patterns with many on/off states. Regarding the screws/potentiometers, I found documentation for mine, but I also had trouble adjusting them adequately.

Hm, I used a custom software from my work (which I can't share).But you can search for Python libraries that convert SVG to Gcode and use that to convert SVG. Alternatively you could change such a library to directly output the format for the laser, which is just on/off and 15bit x and 16bit y.

Cool! I like it!

well, disabling the port write will use digitalWrite(), which does not have to be slow depending on the target platform. It is slow on the Arduino, so portwrite is more direct that digitalwrite. But if the portwrite is emulated, e.g. on the Teensy, then it does not bring any performance improvements.Of course you can optimize the MCP library for your target platform, so you can adapt it to portwrite on the Mega as well or to specific STM32 functions/ports. But as the first step to get things working cross platform I would turn the portwrite off and see how good it works with digitalWrite.

Yes, it should work, but you don't need the controller card which comes with it. The size depends on the angles the galvos can move to and the distance to the wall/projection surface, a typical angle for the galvos is 10 degrees. So you can project on your neighbors house and it will be a big projection but of course for large projections the laser pointer might not be powerful enough.

I don't know what you have ordered. Maybe you can post a link to the scanner you ordered? It sounds like it vontains more than the galvos and the driver cards.

Yes, looks like it contains a controller that can play animations from SD card, although it does not explain anything on how to do that. But I did not see a laser on the item list, so you still need a laser pointer or laser module to do the show. You don't need the controller part, that will be done by your Arduino.

Yes, you can get it to run on an Arduino Mega, but it would definitely be easier if you just buy a Arduino Nano (clones only cost 5 Euros).If you use a Mega you will have to:- change the pins for SPI:Arduino Nano: pin 11 instead goes to pin 51 on MegaArduino Nano: pin 13 instead goes to pin 52 on Mega- you have to REMOVE this line in mcp library AND in Laser.cpp:#define MCP4X_PORT_WRITE 1- to use different pins for the laser, the latch and cs, you can select any digital pin on the Mega and change the code at Laser.cppdac.init(..., 10,7,1)Replace 10 with your Mega pin you choose for CS, replace 7 with your latch pin.This leaves us with the pin for the laser, that is specified in LaserShow.ino in the constructor of Laser().

Probably the Teensy is so fast that the galvos don't move at all.2V is fine, because the MCP only gets 3.3 V and if gain is set to 1X, you get 0 - 2.047V instead of 0 - 4.096 with gain 2X and 5V. Gain 2X does not work with 3.3V because the MCP can not go above 3.3V, so the output will be clamped.Regarding the speed, yes, you need to adjust the Laser.h parameters:improve the quality:#define LASER_QUALITY 8enable the move delay:#define LASER_MOVE_DELAY 5Try putting laser quality between 1 - 16 and laser move delays between 1 - 10.

You are welcome, no problem! I am happy you solved it.

Another thing, the MCP library uses the old deprecated SPI API to set clock speed, seehttps://www.pjrc.com/teensy/td_libs_SPI.htmlfor details. This means the SPI speed depends on the MHz of your Teensy. Try compiling with 96Mhz (which is what I used with my Tennsy) instead of full speed. Alternatively the SPI init code in the MCP library could be changed to use SPISettings and SPI.beginTransaction() to specify a fixed SPI clock rate across all micro controllers.

Did you connect the correct SPI CLK and MOSI pins to the MCP4822?

No, I don't think it is those warnings...Hm, try a minimum example with the MCP library and write 0 and 4095 using dac.output2(value1, value2) and check if you get 0 and 3.3V on the outputs of the DAC.

Try disabling MCP4X_PORT_WRITE on the MCP library header file, maybe the port writing does not work on Tennsy 3.5?On my Teensy 3.2 it worked out of the box, the only thing I had to change was the gain in the MCP library because the voltage is only 3.3V, but even witout changing the gain, you should see an image... If the galvos don't move it has to be the wiring of the MCP.

I uploaded the source code for the spectrum analyzer to Github, I am not planning to write an instructable on that. It is basically just replacing the Arduino Nano with a Teensy 3.2 / 3.5 and adding an audio input circuit. Since the Teensy is very compatible, it is straight forward to switch from Nano to Teensy,

I didn't see the two DACs, that's cool! If they can be set/latched synchronously, the mcp4822 would not be required... Let me know it that works! Regarding the analyzer, I would prefer to clean the code up a bit before putting it to Github. And I had to patch the FFT of the audio library to remove timing glitches.

I cleaned the code up and uploaded it to:https://github.com/DeltaFlo/LaserProjector/tree/ma...I did not try to run it again, since I don't have an audio source right now, but I think it should work. You need to create a small audio input conversion circuit if you want input from a normal RC jack, look here:https://github.com/PaulStoffregen/Audio/blob/maste...I myself used the DAC output of a WTV020sd16p, so I did not need that conversion.For the best performance, you need to get my patch of the Audio library, I linked it in the .ino file.

Yes, but since it is an analog signal, this just means that the galvo will not be moved to the maximum position/angle. So instead of a full 10V positioning range, we just move in a 4.096V range. No harm, just a smaller projection aperture/angle.

ah and regarding the batteries, that can be tricky, since the Galvos need bipolar power -15 to 15V. Probably you could build it with two 12V batteries and take ground from the center of the batteries connected in series. But I don't know if the galvos driver cards will accept 12V instead of 15V...

Its mainly the cost of the galvos (100 Euros on Ebay), DAC 4 Euro, Laser Pointer 5-20 Euro, Arduino Nano (clones start at 8 Euros). When building the amplifier board, add 20 Euros for those parts. I'm not available to build it for you, sorry!

Thanks!

I am wondering if this motor would work:http://www.ebay.de/itm/2430-7200KV-4P-Sensorless-B...with 2mm to 5mm adapter and then 5mm to 8mm coupler?I have trouble finding a cheap brushless motor with 5mm shaft on ebay.de

I used a 3.2, but you should get a 3.5, I think. There is no reason to get a Teensy 3.2, because it is not much cheaper than the 3.5. The source code for the Laser works out of the box, the only difference is that the Teensy is 3.3V so you need to change the gain in Laser.cpp and you need to change the timings because the Teensy is much faster.Regarding the spectrum analyzer, I don't have plan for an instructable at the moment, but I can send you the source via private mail if you want.

That's really nice of you! But I don't really need it since I am not going to build another one. Big thanks anyways!

Cool! I like the oscilloscope idea!

You can also invert x in the code, there is a #define in Laser.h to flip in x and y direction.Funny, I actually did the same, the projector shows date/time, weather report and per date infos onto my bed room wall. I added Wifi so that it can get weather and other infos from the web.

You can draw multiple lines using multiple calls toDrawing::drawString(text, x, y);inside of a loop. The more you draw, the slower it gets ofcourse.

By the way, I really like the PCB you designed. That is completely outside of my skills!

A faster micro controller helps a bit, I am using a Teensy 3.3 (or nowadays a 3.5). The nice thing is that it is almost 100% compatible with the arduino. But don't expect it to get much smoother (maybe a factor of two faster), the final limit are the galvos. When they are driven too fast, the lines get non-linear. You can try that with the Arduino already, if you change the quality parameter in Laser.h it will send less intermediate points and you can see the non-linear movement.A Teensy works very nice to communicate with the esp over serial because it has two hardware serial lines.

Cool project! I am thinking of using a Teensy 3 (fast arduino compatible micro controller) instead of the propeller... Is it really required to use two SPIs to control the two strips, or would it work to use a single SPI and controll all LEDs with it (and keep the LED strips connected in a row)? I also saw there are APA102 strips with 144 LEDs per meter, I hope I can use such a strip to increase the resolution further.What do you think?By the way, do you stream the image from the SD card or do you read it fully into the memory of the propeller?

I just saw that the Teensy 3 can do 2 or even 4 SPI outputs for APA102 at the same time using FastLED, as given here:https://github.com/FastLED/FastLED/wiki/SPI-Hardware-or-Bit-banging

Congratulation! Regarding the pin 1, you are right, that is always on the left of the half circle (or directly indicated by the dot). The name is flipped by the Fritzing tool automatically.

The Nano does not have enough memory and is too slow to handle the interactive part. I did some experiments with a Teensy 3.2 and an ESP8266 so that you can draw something on a HTML page and it sends the drawing via HTTP post. That works but is not fast enough to run at interactive framerates.Maybe a Photon with buildin Wifi would be fast enough. Alternatively it surely can be done with a RasberryPI.

Well, the laser can only draw lines, so you will have to create lines in Processing and send those back to the Arduino. The Mega has 8 KB SRAM, so if you can use maybe 4KB of it for a buffer, it can store 1000 points (4 bytes per point). Since you want to communicate with Processing while drawing with the laser, it might get tricky to communicate via serial and at the same time draw with the laser. Maybe you could rewrite the laser drawing code to run in an interrupt, but I doubt the Mega is fast enough. I guess upgrading to a Teensy would do the job, but would still require some interrupt magic to get both serial and laser running in 'parallel'.

Yes, I2C is too slow and a dual channel DAC is easier to latch synchronously. And with the MCP 4822 no extra components are needed. Thanks for the details!

Great! Which galvos/laser pointer did you use?

I cleaned up the script a bit and added it to Github, I hope it helps you guys:https://github.com/DeltaFlo/LaserProjector/blob/master/Scripts/convertGCode.py

I will see what I can do... It is not very generic nor cleaned up. I guess without cleanup it raises more questions than it helps.

I upgraded to 1.6.12 and worked around the problem, which indeed is a compiler bug. The fixed version is on GitHub.

Look for a laser pointer powered by three 1.5v coin cell batteries. I did not buy mine, it was an advertisement present.

To get nice 'linear' lines, I have to split each line into small segments, otherwise the galvos move non-linear and too fast. So although my objects have less than 800 points, the overall positions that the galvos move to are more than 800 points on many objects. Another thing to consider is that the laser on/off delay is 400ns (for my laser pointer), so each separate contour cost extra on/off time.And the 20k does not really mean that you can go 20k from 0 to 4096, it only means moving 20k times in small fractions.

The nodal points are less visible to the human eye than to the camera. The reason for them is that the laser pointer stays longer at these points. It is all a tradeoff between speed and visible quality. You can play around with the parameters in Laser.h. If you reduce the waiting time, you will get less straight lines but also less nodal points. Upgrading to a faster microcontroller also helps, e.g. a Teensy 3.2 can be used as a drop-in replacement.

I wrote a Python script that transforms gcode to my hex code. The hex code is really simple, just 15bit for x and 16bit for y and one bit for laser on/off.