Cameras
-
Aren't there two SPIs on the ESP8266? What GPIOs are currently used (and for what) in the present implementation?
EDIT: looks like one of the SPIs is used for the flash chip. Does the firmware fit into ESP8266 RAM, or is the flash actively used during operation?
Perhaps use I2C instead?
-
I kinda like the fact that there is no setup for a camera (besides the stills), and heres why.
I would like to be able to monitor the print from outside of my home, but I don't necessarily want to open the duet (and full control) to the outside world. With a Pi I can set up a wireless camera system using motion, and if I really want control over the printer (say to stop a print if it goes awry) I could rig up the Pi to have an estop command to run an Estop routine (stop print, home machine, cycle/cut power since you can set up macros when a pin goes high or low on the duet?), and then setup the Pi so I can access a web page from anywhere to view/stop the print. It would take the load off the duet (for the camera) and help protect the control of the machine from unauthorized use, since its still constrained to your local network.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
-
For my desires a dedicated Pi would work really great, but I can see why you would want it all in one. I was just adding another viewpoint into the convo in case you/someone else hadn't of thought of it like I have.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
-
If it's just a SPI/i2c/UART header, then it adds no cost and you're free to use/not use it as you see fit.
In my opinion doing IP cameras only is bulky/expensive.
ITs not the cost, its the adding a header into the SPI circuit which may degrade the speed achievable even if nothing is plugged in. The UART would not be an issue from that perspective, however it would be rather slow.
Yes, I know about the length/speed relationship on SPI - I've done board/firmware design with SPI in the past. That's why I asked about the second SPI block on the ESP chip, and whether it was available. If it is not, then I'd suggest i2c.
-
The second SPI block on the ESP8266 is used to read the code from the flash memory chip. So it's not free, and although I understand that it can be shared, adding 1m or so of cable to it would not be a good idea (and adding a camera to my delta would need more than 1m of cable to the electronics).
I2C is also intended for very short distances. It relies on pullup resistors, so adding more than a small amount of capacitance on the bus degrades its maximum speed.
So UART is the most practical option. The highest resolution supported by the Adafruit camera is 640x480. So I took one of my photos of my delta printer looking down on the effector and resampled it to 640x480. The file size was then 100Kbytes. If we can use 115200 baud (the maximum supported by the Adafruit camera) without dropping characters - which isn't necessarily the case - then it will take about 10 seconds to upload an image, if the camera uses about the same Jpeg quality/compression compromise.
A 640x480 image is actually rather large to fit in the existing slot in DWC, so an miage with lower resolution might be acceptable.
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
-
While i get the intent to make a self contained solution, I think video might be a step too far. If the ESP can server SPI video well if there is a spare SPI port then how about using a second ESP for the video?
Which brings us back to this solution http://johan.kanflo.com/building-a-low-cost-wifi-camera/ that Tim linked to in his original post.
-
yes, that would work - but effectively we are making an IP cam. I suppose we can add a bit if we allow trigger via UART so we could get good timelapse recording.
-
I don't think a second ESP is a good solution, that's buying more hardware when you have a perfectly good ESP sitting there doing very little during a print.
It seems as though with resistor pull ups, you can have 200pF of cable capacitance on I2C. That'd be around 15 feet with this cable, for instance:
https://www.wireandcabletogo.com/uploads/file/bel9841.pdf
I've done both SPI and I2C over the types of distances we're talking here (a meter or so). While I agree the high speed SPI would likely be affected, a slower bus should be fine. I think interfering with the UART isn't a good idea, since that makes it harder to do ESP firmware updates.
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
-
Hmm, I hope I don't come across as rude, but why would a 3D printer need a built-in camera? Seems like too many systems tacked onto the wrong hardware. I've found that any PC with a webcam works well, and is more versatile. I only see drawbacks to trying to add a webcam to the 3d printer controller.
-
Lots of reasons - time-lapse, remote monitoring, etc. It is a really popular feature, otherwise Octoprint wouldn't have it.
Why tie up a PC, and spend the energy running the PC, when there's hardware on the controller that is sitting nearly idle?
What is the drawback to adding a webcam to a 3D print controller, exactly? Its maybe 5 cents to add a header to the board, free to do the routing, and even if Tony/David don't want to spent time writing code for now, at least it can be added later.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
-
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system. A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
-
I have some sympathy with bot's view. A streaming remote view of the printer might have some value, and I can already get that from the £20 wireless IP camera that I purchased recently. But I don't think a static image refreshed every few seconds adds much to the web interface.
We're getting very close to the point at which we need to freeze the hardware design. Any changes we make at this point should be for the sole purpose of addressing issues that arise during the beta test phase. That said, I am not against adding a 5V pin to the ESP comms header, or adding the 3 spare ESP GPIO pins to that header if there is room for them.
-
What are the GPIOs currently used for? If some are unused, why not bring them out to a header?
Which ones would you want on a header?
Any that are unused, for future proofing - at least enough for i2c. All the SAM's pins are used/brought out to either do things or sit on an expansion header, so why not do the same on the ESP?
@bot:
I understand the use of a camera, but it is nearly entirely separate from the other functions of the control board. The web interface is not publicly exposed, so it doesn't really make sense.
The web interface can be publicly exposed if you forward the port on your router, but even if you don't do that, being able to watch the print from within the LAN is useful. Personally my printers are in a closet (in the same room as me), with a closed door for noise reasons. Having a video stream lets me watch for print failures easily while sitting at my desk. I can even bring it up on a laptop if I walk to another room to work.
@bot:
I'm all for adding features to a controller board, but I fear that some people are losing sight of the important aspects: reliability, accuracy, fundamental features of a motion control system.
No one is losing sight of anything, all I'm suggesting is that the pins are brought out to a header so at least it can be developed later if people need it. Things are very close to a hardware design lock, at that point there's no more "oh I wish for xyz". At least by bringing the pins to a header it can be developed in software at a later time. It would take about 5 minutes in KiCAD, that isn't a significant diversion in resources.
@bot:
A webcam serves no purpose whatsoever. Why does a webcam need to be tied into the system that controls stepper motors? It doesn't, and shouldn't be.
I have outlined my personal use for a webcam above, but if nothing else having webcam functionality will be an attractive feature on the Duet Wifi to help it stand out further amongst its competitors. In my opinion there is no reason not to do it, the hardware is sitting there nearly idle otherwise. It doesn't take away from the stepper motor control, since that's all handled on the SAM.
-
Your use of the webcam indicates no reason it should be tied into the controller board. Yeah, I use webcams too for my printers, but I do not need the image of that camera to be processed by the tiny controller board running a very sensitive process.
If it's a matter of adding some trivial changes, okay, fine. If you ask me, these kinds of things (including wifi itself) should be specifically left OFF the board, to prevent potential unforeseen problems.
Also, exposing the web interface publicly (at this point) would be amazingly stupid, unless you don't care about your house burning down or you can trust everyone who may come near your wireless network with 100% certainty.
-
Why should someone have to buy more hardware when there's a perfectly good ESP8266 sitting on the board not doing anything else during the print besides updating a handful of numbers, none of which are time sensitive? I'm not sure I understand your argument, since the ESP is totally separate from the motion control system - they just happen to be on the same PCB. You could drill a hole through the ESP8266 mid print and the Duet would happily print away.
If you don't want to use a camera with the Duet Wifi, no harm no foul. If the header isn't there, then no one can use it ever. Additionally, all the pins of the SAM are brought out, why not do the same for the ESP chip - they could be used for something other than a camera even. All I'm suggesting is to bring the pins out for now, worry about the rest later if it ends up being desired/feasible.
How would someone burn your house down with access to your printer? If the printer is powered up you should be on the premises, and your maxtemp settings should be such that no fire can be auto ignited - otherwise you're just a typo away from "burning your house down". I think Duet Web Control has password protection anyway?
I believe I saw elsewhere you use Teamviewer for your prints - are you aware of the security issues they've had?
-
The ESP8266 is the only means to control the printer if you do not have a paneldue, it is simply not worth compromising (any further) for sub-par camera functionality, when better functionality is already built-in.
You already have to buy a camera, so your point of additional hardware is moot.
You can change all the firmware settings, which IIRC, include max temperatures and the like. I could set the e3d to melt down, could I not?
Thanks for the heads-up about teamviewer. It is still worlds more secure than simply exposing the duet web server to public ports.
