So it been a while since my last update, my lil’ dog of 16 years had to be put down and I wasn’t feeling it, then family visited from so we stalled abit.
So quick updates for the tl;dr people :-
- Head rotation works, but have to add an encoder wheel since we ‘forgot’ about the tool home position inside the head tool pickup…
- Y axis is all upgraded, new stepper motor drivers are in 1/2 step is on.
- Switched to GRBL and StepDir, instead of, uhh, not stepdir.. Though using the
- OpenPNP base firmware revision, i didn’t realise it was different til after porting it.
- GUI is almost done, it can place one full board from feeders and trays
- Replaced hoses as the old ones burst, which only happens when you say right lets video this.
- Trapezoidal for the servos courtesy of Grbl.
- Still having some issues with the vacuum sensor, might be bad or low pressure or something else, turned it off for the moment.
So we’re able to pick up and place with the new Grbl firmware and the updated GUI, its all GCODE now. I’ve moved more of the functions into the GCODE vs individual move, drop , vacuum, since the communication is just serial rx/tx and serial is a PITA for this sort of thing, since its all ACK/re-ACK. With an M command its just e.g. M21 pickup part, M22 putdown part and the machine reports yes/no. FTDI’s are decent chips but they will break down comms after long datastreams, I’ve had a lot of problem with them and high speed streaming, as well as overlapped IO support is meh, events don’t work that well so multithreaded serial comms based on events is in theory great, but the practise doesn’t always work well. so its all software handshakery.
We’ve done a lot of changes since the last update.
Grbl’s great, its easy to use and easy to add on too, we were already using the AtMega2560 anyway so lots of space, even with all the stuff I’ve added to it, we’re at maybe 17%of the flash space. I had looked at it when we first started out, but it needed StepDIR and were using – + , our original drivers didn’t support StepDIR. Even luckier I’d put all the stepper controls on the same ports.
Changes for the 2560 are minor, just an interrupt rename and i don’t the sleep mode is working as it ought too, i assumed it was and then wondered how to handle the panel switches but turned out when i added the head movement ACK that it was, I was going to use timer3 to handle switches but then i noticed the main loop was executing constantly, some of the AVR’s have different sleep rules.
One thing i did do though is since the mega ICSP is under the shield and its on the machine, which is 3 metres away from desktop. I left the Arduino serial boot loader on the chip, this way i can just script AVR Dude to load the firmware built in AVR Studio 4 to the mega over serial. so its a lot easier, the downside is that if you press a key too soon the boot loader seems to kick in, i haven’t checked this to be the reason for sure, but it seems like its that. Not a huge deal.
Running a test of the GUI
Head motor, luckily we used a double ended shaft motor in case we needed an encoder, which it turns out we do. Look closely at the top of that shaft, see some thread? yeah we didn’t…. We CAD’d up a mount and fitted the motor.
The motor is 1,000 steps for a full 360 degree rotation, should be able to place the craziest of our boards, we like some gangsta lean in our part placements.
As a side note the magnetic sensor on top of the head, really don’t like the way they’re made or mounted, that wire takes a beating and it’ll fail again so we have to fix that too. You can see all our temporary fixes for the hoses that keep cracking, they’ve lasted 20 years though. The red line is the new one we’re using, which is way more high tech than what was available in those days, it should last longer than the tech is needed.
The rotation head needed a larger power supply, so that is now installed. Its the 24V power supply previously mentioned from all electronics.
Since we made the shield with the extended pins its easy to add things on to it. And now we’re on StepDir its just one wire to control the head ( Though we make a semi-fatal error at this step in choosing which direction the motor runs )
Setting up a test
After the rotation head was added to the software, i test placed two parts, they’re off, at this point i think its the solder paste or tape missing, so we add some. As you can see though the parts are rotated as they should be. We were uStreaming with the second camera so its all hanging off in space at the moment.
Krs adds some paste to the test pads. She’s the one who wants this thing finished the most as she builds most of our boards
I’m remotely moving the head with the camera view. First home, then moving to the PCB to register the location of the part, then going through the steps of the part placement.
So the mistake in the choice of direction for the head rotation is that the head can unscrew itself and drop down the tool, the sensor doesn’t know the head is down and the tool is now below the PCB holder and auto changer, so the head will gleefully zip around and bang it into whatever it can find, which bends the head, which is not good at all. So we’ll reverse the direction of the motor and use lots of Loctite. This is why the test videos show the parts poorly placed.
Pity these lessons learnt cost us a head each time.. But we move on..
A trial run through all the parts ( using 1206 resistors since they’re like .00004 each) as you can see they placed perfectly.
Ok, maybe not what you’d call perfect but they did place in the right spots, the head down motion was a little too strong and there’s no paste to hold the parts in place so they’ll wander around every time a part is placed. Still the software is working.
The vacuum sensor needs to be set quite accurately or it’ll do things like this :-
The tool is sitting perfectly on the vacuum test pad, the head brought it down to see if was there, blocks the air coming through the tool, but since it wasn’t picked up correctly ( head wrong orientation ) it just left it there.
The head moves to the pad, goes down, the air comes on, there is a settle time, then the machine reads the vacuum sensor, if its not blocked there is no tool, if it is, then there is a tool. That is how it decides if the tool needs to be picked up or put back.
Finally we place a board with paste and all !
So last night(this morning) we finally managed to run a real board. For some reason i decided to go through each of the components and rotate them 90 deg rather than change the rotation in the feeder…. derp… As we did this the vacuum test failed, so you can see me going in change the code ( incorrectly!) and re running, it the bit you might not see is the machine doing a loop of picking up a part… i fix that and we move on.. First run we do a step by step. I noticed a few bugs as we go along so there are some pauses as we fix those.
Stencil pasted a board, you can read about this in our Arduino Mega build blog entry. Its a CNC’d brass sheet.
I taped the board down to stop it moving around, probably not needed.
Some of our feeders need some love and i wasn’t super careful about where i was picking up the parts from so it was a little sloppy, however it was 2AM and i ended up having to leave and come back after one of the alarms at work went off
MMCA used one of his awesome swiss files to ‘fix’ one of the feeders that was catching
Here are some more GUI videos, they’re probably only interesting to those of thats like watching these things over and over..
Annotated some of the steps in the GUI.
One of the feeder pickups i didn’t setup properly, so it was placing them off!
Onto the hotplate, i wanted to see just how bad we could place parts and if they’d fix on the plate, all but one pulled onto the pads, the other worked but was right on the edge of a pad, it’d work fine. All we have to do is take more care when tell it where to pickup
Krs also has a bunch of videos of the machine placing that first board.
Anyway that is mostly it, we’re down to the tuning and bug fix stage so its been pretty fun.
But if you’ve got minerals help out the OpenPNP guys they’re doing good work, our stuff is available to everyone, but its reasonably specific to the Juki though it is GCODE.
Small update: Last night, I started adding the second USB port of the ADK to Grbl as well, its almost finished. I based it on the usb.cpp from ADK but i converted it to C since the c++ generated a larger firmware and there is only one USB port, I want to keep the firmware tight.
BTW If you’re reading this and are on the yahoo zevatech list the moderator who’s apparently building a commercial retrofit for this machine is blocking our posts sharing this open source project. He said he wants credit for a CPU suggestion neither his or our project uses, a fix that wasn’t broken, and a camera solution we didn’t ask for advice on, or use.
Miss you girl