V4 shredder arduino code
- This topic has 27 replies, 7 voices, and was last updated 2 years ago by .
Dear forum members,
We are working on a version of the shredder that can actually shred for a few hours without somebody having to watch it permanently. in order to do this, there’s an arduino standing over and watching the machine permanently. The arduino monitors the current through the motor to see if the machine isn’t jammed. It tells the world how much current it is drawing over an LCD display. And the arduino has the power to change the direction of the shredder or stop it.
I will drop the code and schematics here. Comments are more than welcome. Also if you think something needs clarification, please tell us. This will make it possible for us to make comprehensive instructions later.
———————–this forum doesn’t really do autoformatting————————
Check the github page 🙂
Updated schematic layout:
Thank you. In your updated schematic, perhaps rectifier is a more common term….
Thanks for the response
hmmm…well…that’s embarassing. I wonder how that could have happened. Anyway here’s a rectified version. I put some more letters in there, hoping it would be easier to wire.
I guess it should be possible to mod this version to fit a single phase setup or a v3 machine. The display is optional, but it’s cost are marginal compared to the rest of the components. It is also quite useful because it shows you the workload. So if you slowly pour shreds into the machine, you see a gradual increase of the current. That means you can see how far you are pushing the machine. Without the display, you would only know when it is jammed, i.e. when it’s too late. I guess in the long run you would be cheaper off having the display. I think it is better to pay 3 bucks for a display than to pay for a new motor for your twisted axle.
But it is on GitHub now.
Do you guys think there is a need for a more graphical representation of the wiring in the sense of a photo or a sketch, or you think a video is enough already?
Can I assume everybody knows what a contactor is?
Should the video include a display of the schematic to show what parts we are working on at that moment?
@dirkvanvroeger. right, thanks a lot. I just wanted to point out that as PP vendor we rather prefer to opt-in into features rather than the other way around. Features are great if you can maintain them in the long and I have a hard time imagining this LCD for our clients. The display is possibly great for the DIYers but to have this for schools and other contexts there is quite some extra work involved on our end.
I don’t know how open PP is at the end is btw. but speaking of adding of new features built on top of your work, would be nice if you could use a readable font and the diagrams can be translated, also subject for instruction & help manuals.
The next feature we have since long on mind : readout and upload shredding, injection, extrusion performance and detail data of a workspace, per plastic type & location via mobile app. Eventually also subject for a reward & plastic currency system 🙂
@dirkvanvroeger; if you like I can do the code changes for opt-in features and vendor/open-source friendly when I am back from vacation around the 15th. I have 25 years C++ background and I am happy to help 🙂 Technically the code has to re-structured via Macro expansions like in the Marlin firmware.
@dirkvanvroeger Your original chart gave me a good laugh…and I didn’t get coffee on the keyboard.
A logic flow chart, if you have it would help. One can get it out of your arduino code but it is not as visual.
Yeah, a 2 or 4 line LCD is a trivial add to the arduino. Perhaps even add an alarm buzzer.
Great work, thanks
I am polishing and merging the code for a Pull-Request on your repo ; just a a few questions :
1. what license ? I’d like to see GPL here; also addressing problems with commercial units in the long
2. could you please finalize the components list in Markdown format (see ‘markdown table generator’)
3. could you please add the diagrams to the repository as mentioned and as well update the readme.md file for the software needed to edit the diagrams. ‘Fritzing’ would be fine
i’d like to implement this file/folder structure (still unclear to me):
– macros (ENABLED, LOG,..)
– boards (board specific)
– auto-reverse.ino (v3/v4)
– auto-stop.ino (extrusion) , still unclear
I can do a logical flowchart of the arduino sketch.
I am pretty sure I do not understand what you are saying.
From your previous post I understand that you want to do a modular piece of software for the arduino where users can generate their own sketch like in Marlin. So that you can decide if you have a one-axle or two axle machine, one or three-fase power (maybe a 24 volt version for schools?) optional hall sensors, displays and button setups? Am I right?
If I am, I think it is a pretty good idea. But I also think it is a bit too ambitious for the scope of version 4. At least the assignment I got was to make a machine that can shred without somebody having to constantly monitor it. If it’s up to me, I will finish that job before I move forward to the next stage. That is something I need to keep at least a bit of an oversight of my own work. But this idea is definitely that next stage. Feel free to do it, I can check if it works here 😉
The only objection I can see is that a shredder is a bit of a dumber machine than a cnc machine. I think up till now, the arduino code is still doable for somebody who worked with it before. Maybe we will never reach the stage where a modular package as you propose is needed. But maybe, we will hit that stage once you make this piece of software.
all I am asking is to setup the code and project up in an open-source friendly way and so others can fix and extend your work. That’s what I meant with ‘not sure how open / conform’ PP really is. The last time your team uploaded something to github there was not even a way for the community to fix critical things like material bills or incorrect component lists. It would be nice if PP Eindhoven can learn from the past and would be open to an open-source oriented mind-set rather than leave us with with broken content and one-way communications for years. So please, just create a simple arduino project, a readme.md file, the diagrams (editable), component list etc… just as you would do for any opensource project; nothing more than this. In the future others can fix and extend code on the go. You may not realize right now but machine builders have always lot’s to add/fix during production. If you block that back-flow by improper open-source practice then you create again just fragmentation and extra work for us which is pretty expensive for us at the end.
I’d love to contribute to this project as open as possible. How open PP really is, I can’t really say. I am just another cog in this machine trying his best to be as open as possible. If it is not up to certain standards of open source projects, it is not because I do not want to, it is just because I am also just another guy wanting to contribute and starting where I can and not being able to be aware of every convention there is. I guess that is both the blessing and the curse of open source: anybody can contribute and not everybody knows everything. I am here in Eindhoven for four weeks now, so I don’t think it is reasonable to ask of me to be able to learn from all the mistakes in the past.
I don’t know what is in a readme.md file, but components lists are coming up.
The schematics are as open as they get. Seriously, try opening them in inkscape.
Here’s that flowchart:
Great, good to hear. how about that: just upload all you’ve got, I take care about the rest when I am back, as PR and template for similar PP firmware. I understand that this sort of component may look too trivial and simple to apply best practices but I can tell you that us/someone who finances a number of projects with sales of this heavy equipment; it’s crucial that everything is being delivered in top quality, not just for user but also for joint venture investments or follow up projects/products. I can imagine a ready to go controller with inverter, enclosure for v3/v4 single/3phase motors will do quite well. Next candidates are metering sensors/interfaces; sounds like overkill for some but to us it represents another stone on this pretty bumpy way to actually do something 🙂
Since it is intended for unattended operation and you are sensing current, perhaps it would be useful to add a “hopper empty” or not feeding signal (light?) based of low current for an extended period of time.
I’ll dump whatever I have here. We were thinking about a small piece of video on the wiring. I am trying to get all components together again, When I have that, I will drop a list with pictures here.
I think a “Hopper empty” function could actually be introduced also on the basis of the current sensor. I just checked my notes to see if I made screenshots of the serial monitor readout, but unfortunately I didn’t.
We are waiting for a motor to be delivered for the shredder for already 7(!) weeks, so I wired the whole schematic to a single axle version of the shredder two weeks ago.
When you switch the motor on, the current readout goes to a certain level. And as soon as the motor actually starts delivering work (i.e. when it is shredding) it goes up a bit more. So the current readout can’t just tell us if the machine is being blocked or not, it can also say if it is shredding or just spinning. The exact values of the thresholds are probably machine-specific, but with a little calibration the “hopper empty”-feature can probably be included with little effort.
Basically you just add another loop for the current being too low without the whole stop-reverse-stop cycle. You check the time just as in the jamming loop. If the shredder keeps going on without any resistance it might politely point this out.
Great work already 💪
I found the github repo a bit difficult to read to I have it a remake, it should be merged by now, maybe it is handy to mention the repo in the original post so people can easily find it.
I haven’t looked into the code but I like all the comments in there, makes it a lot more readable 😀
Earlier you asked about the connectors, here is a link with background on board-to-wire connectors. http://tech.mattmillman.com/info/crimpconnectors/
great, @dirkvanvroeger. thanks for the pdfs, could you add the source files as well ? (would be great to have the real source files for anything else as well, PP wise; it takes a good chunk of time on our end to reconstruct this material otherwise, … ). thanks again.
This forum doesn’t like svg-files, but the pdf is actually editable in inkscape and has the same information. Inkscape doesn’t care if you work in a pdf or an svg. But I’ll send the svg’s to Jerry. He can dump them in the GitHub. Also there is a detailed “how to” about the wiring in the making. It is coming up soon.
@dirkvanvroeger, Hi again; I am integrating and testing your approach but having some trouble. Could you add the list of components please ? For interfacing via relay the inverter won’t work with inverters we usually use … There seems also an issue with the code. Any info when this is being re-iterated would be nice too. Thanks again.
I took these from the how-to that is in the making:
2 contactors for 3 phase motors, preferably with 3NO and 1 NC connections.·
A 3 phase current limiter that goes up to about 6,8 Amps.·
Wire, for both 230 V and 5 V·
An emergency stop switch with three NC connections
an Arduino power supply (5V),
a standard arduino relay module and a hall effect sensor module (ours was set for 20 amps)
A switch with three permanent states: forward, reverse and stop.
a 100 microfarad capacitor,
two 10kOhm resistors,
one 100 kOhm resistor,
a really large capacitor (we took 2200 microfarad)
Thank you very much. I am ordering now 🙂
My biggest concerns are those pin – header connections ( -> screwshields) for the DIY version. Those could loosen (plastic glue?) when the enclosure is mounted on the frame (shock-absorbers?). However, I am integrating your solution as soon we have the parts. For now, I am testing an enclosure, simple sandwich style. In the picture below : arduino, buzzer, relay, 24V -> 5V transformer (inverters supply this mostly already).
I am heading next for a commercial version of a shredder & extrusion combo controller and will try a RPI-7 touchpanel , not just for having settings more accessible but also to select between different profiles. fun stuff 🙂
Other than that, I just got my head into PCB making (outsourced, using eagle).
thanks again and enjoy 🙂
@ppboys , you can get some of the arduinos without headers and solder the screw shield directly to the board or put your connections on a separate protoboard and avoid the pin->header connection
We have improved responsiveness of the code, changing from delays to state machine, and also added the possibility to configure via serial without the need to recompile.
Code is updated at the github, and we will be improving in the coming weeks, including PCB and configuration GUI.
On the long run I want to change contractors for power electronics so we can do soft starting on the motor, but for now I will have to focus more on the plastic identification sensor, so if anyone is interested in helping out, it would be great.
See you around 😉
nice thanks a lot for the update – looks great now. just a few couple of things I noticed walking through the new code :
– indeed, there needs to be a delay when changing direction – we had recently a user shorting his circuit due to his relays
– the 3000 ms delays shouldn’t be hard-coded 🙂 there is lots of time you can save tuning those parameters. especially adding a variable for breaking and acceleration time – makes sense since those are mostly quite different
other than that, I felt more confident and satisfied after weeks of testing different hardware:
– ignore direction switch when powering on -> user has to explicit go to stop and then set forward
– adding a boot delay (ignores all for some time) – also due to weird switches, relays, …
– do explicit checking of ‘running’ state after a direction change – to make sure it isn’t fully jammed = fatal mode instead of trying auto-reverse
– ‘machine builder’ wise, adding a functionality to patch configs via includes per tenant base makes things easier. you want to store those configs in separate files for each customer.
– debounce your switch/button signals 🙂
– there is often VFD error terminal you could read (over-torque)
ah, and one thing I’ve still to do : handling the unsigned long rollover after 30 days or so.
cool to hear about the PCB – we had similar on mind but since there are quite more hardware we’ve added and possibly other things coming up – we decided to wait til all settles. the configuration gui is also in our queue but mostly done with custom IDE for hardware interfacing.
@alromh87, if you like, I can migrate all the mentioned machine & human safety behaviors in your code because let’s not forget, we’re handing here the control over a pretty deadly machine over to an algorithm and a stupid cheap controller … and from what I’ve seen this can go quickly ugly and unpredictable …
I would be happy to see this plastic detector thing happening 🙂
@ppolice help would be really appreciated!! but I have few thoughts on some observations:
I will change the 3000 ms delay to be configurable, but actually the code is using current sensing right now, so I haven’t decided if time should not be used at all for this part.
I’m not sure of the need for boot delay.
Code has now implemented configuration via serial command and saving to EEPROM, and I have the feeling that’s easier for ‘machine builders’ & fine tunning. To use this feature you just need to send via serial(115200):
If you could implement a GUI to send this command would be great addition, and could event store per tenant configurations on the GUI. 😉
Thanks a lot for the interest and availability to improve this together.
Alright, I will do this in fork of yours over the weekend 🙂 see you in a bit.
About the GUI – whilst this is easy and fast todo in our IDE which spits out web-apps too – I think pulling in ‘user_02_config.h’ is the more straightforward compared to run some app which still needs serial port access.
You must be logged in to reply to this topic.