Any basic estimation on the final price? Like, nearest hundred is enough.
Any basic estimation on the final price? Like, nearest hundred is enough.
My main feature request *I guess it's hard though*
You told me on IRC that it's processor is quite good.
How about you make an good use of that SD capability and make it that you can develop programs that execute from the SD card without having a computer connected.
Maybe A little display that can be attached on the dac which give you a little degree of control.
This can be practical is someone wants a very compact setup at times, it's off course by far no replacement of the pc, but it's a nice feature
Support for the spaghetti is a great idea I have also bought spaghetti program
Way cool that you are making this open source. I think the most important thing at first is compatibility with existing tools like Spaghetti, EasyLaze, etc.
Longer term I would be interesting in helping with programming on the ARM or PC side. I'm very interested to work with a DAC that has an good programmability model. I have a sound card DAC that is useful but not super reliable. I love my FB3 but there is zero programmability.
What do you think the parts cost will be?
Thanks,
Mike
First, awesome idea and a nifty looking project!
I'd consider adding UDP support for local host-based show streaming, unless you're sure you 1) want to and 2) have the horsepower to buffer and support TCP for what amounts to a real-time display. If you drop a packet, sometimes it may be better to skip it and move on than to spend a lot of time recovering it.
There is a hardware WDT in the micro and the power up reset on those things is pretty robust these days.
Power input is via a switching regulator with a very wide input range, the analogue stuff will go south well before the cpu does and the interlock relay needs a pin to be toggled to hold it in, either steady state will not keep the relay pulled in.
Thus even before the WDT fires the interlock will open as the micro fails to keep the interlock pin moving.
On any future V2 it might be worth thinking about hooking a couple of comparators to keep an eye on the various DC rails so the interlock can respond to a low power rail condition.
Much thought has been given to stationary beams, and actually the safest thing to do (if not the prettiest) is to close the shutter and zero the colour signals until the host processor gives an explicit restart command (still move the scanners, just dont radiate until told to).
Of course most of the firmware still remains to be written, and I dare say there will be much experimentation with different approaches.
Regards, Dan.
You need to ensure loss of comms results in safe operation, not just loss of rails or CPU watchdog timeout.
I have worked as real-time embedded developer of almost 20 years, if I can help in anyway, please just PM me.
This space for rent.
Here's a first whack at things. Thoughts?
https://docs.google.com/document/pub...byfluWNHM7Li5k
Google Docs is doing strange things to the formatting there. I'm going to move over to a proper wiki or something tonight.