[neilw20]

As is often found with these things, buried in errata sheet (eventually). I had a problem with another brand chip, and during power up the transition from detecting rising supply rail caused an undocumented spike in supply current so the rail dropped slightly and made a complicated oscillator! AND the clock never got going, so the watchdog never got going. Manufacturer visit uncovered the problem -- not documented, till I found it.
Solution: Specified supply capacitor was too small.

[sagreen]

Sadly, this has not been a good week. I completed the FPGA design last week, and most of the bread-board to interface it to the Arduino. Unfortunately, it appears the FPGA on the board I bought is defective. The logic I designed works perfectly in simulation, but in the real hardware it frequently misbehaves in ways that the logic dictates is impossible. I've been able to determine exactly WHAT is going wrong, but can come up with no explanation as to WHY it's wrong, other than the internal logic of the FPGA is faulty. It is absolutely not an error in my logic (I did do chip design for a living for over 25 years...), nor a timing problem, as the error occurs even when running at extremely low speed (manually sequencing input signals), and the logic is very simple. So, I'm pretty much dead in the water until I can get a replacement FPGA board. Very disappointing....

I'm also considering what the core controller for the production ATC will be. I'm seriously considering switching from Arduino/USB to Raspberry Pi/Ethernet. It is a bit more expensive, but has a great deal more capability.

Regards,
Ray L.

Ray, check out Netduino :: home Not sure if you have messed with these but they are great. Grab a netduino plus V2. You code them in C# in microsoft visual studio. Pin compatible with an arduino, but a ton better to develop with. Personally I would use one of these before a Raspberry PI.

Scott...

[SCzEngrgGroup]

Ray, check out Netduino :: home Not sure if you have messed with these but they are great. Grab a netduino plus V2. You code them in C# in microsoft visual studio. Pin compatible with an arduino, but a ton better to develop with. Personally I would use one of these before a Raspberry PI.

Scott...

That is attractive! c# is my favorite language.

Regards,
Ray L.

[SCzEngrgGroup]

I finally caught a small break! I designed a different, slower, more complex FPGA interface to the Arduino, and it compiles and operates correctly on the real hardware! I'm certain the FPGA is defective, but I now have something that at least works well enough to make some forward progress, even before the replacement board shows up. I've already tested the PWMs and encoder interfaces, and all are worked perfectly right off the bat. First thing tomorrow, I'll be able to wire the FPGA up to the ATC test system, and start testing it out under real-world conditions!

Regards,
Ray L.

[SCzEngrgGroup]

Made some good progress again today. The electronics is all updated, and the new FPGA logic is working perfectly. I spent much of the day "re-factoring" the firmware, to make the hardware drivers more modular., as I expect to be using a variety of different encoders, H-Bridges and other components on the production hardware. I'll now be able to use the same core servo driver with any PWM, encoder and H-bridge. I should have that finished up mid-day tomorrow, and be able to get the ATC running on its own again. Once that's done, I can get back to work on the hardware - moving the transfer arm encoder to the arm itself, instead of the motor, and getting the lower bearing mount in place. It should be mostly downhill from there.

Regards,
Ray L.

[SCzEngrgGroup]

I'm happy to report the new servo code is about 99% working. I've got a couple of issues to deal with yet, but it's mostly behaving well. With the new hardware PWMs, which run at 10kHz, the servos are now nice and quiet quiet - no more growling and whining. Now that I'm not losing encoder counts, the motion is smoother, and I am confident I will be able to tune for very snappy performance. Even now using PID parameters that are far from ideal, the response is looking pretty good. With the improved encoder interface, the dithering is greatly reduced, and I know can be reduced still further by better tuning. The FPGA was definitely the right way to go.

Regards,
Ray L.

[ram48]

hey Ray
When will the English version of this thread be available?
Keep up the good work. I enjoy reading about your progress even if I only understand every third word.
Ray Mc

[treyjugson]

Is this with the new FPGA or the old one that was bad?
trey

[SCzEngrgGroup]

Is this with the new FPGA or the old one that was bad?
trey

Still the bad FPGA. I should have a replacement in a few days, but in the meantime I managed to work around the faulty logic.

Regards,
Ray L.

[SCzEngrgGroup]

Whew! Spent the last several days working hard on the servo driver. I've finally had a breakthrough, and it's now very nearly ready to go. The ended up tossing my entire trajectory planner, and instead going with a much simpler exponential approach. I also added velocity limiting, and now use different algorithms for long and short moves. The result is much faster positioning, and it deals with the backlash very nicely. I can go from any position to any other position in about 1/2 second, and end up within just a few encoder counts from the target - at the current 8192 counts/rev, that is MORE than close enough. The best part is the latest code requires significantly less CPU bandwidth, so I was able to go back to a 10mSec update rate. When I get a faster processor, I should be able to easily reduce that to 1mSec, for even better performance.

I also now think I will likely be able to come up with an "auto-tuning" algorithm", so the servo can be easily re-tuned periodically to compensate for wear, friction, etc.

I'll try to get a video up later today.

[johnedward]

what, no love for tom at kflop? http://www.cnczone.com/forums/dynomo...p-related.html

[SCzEngrgGroup]

It's mind-boggling how juvenile some alleged "adults" are....

[johnedward]

you think it's not the adult thing to do to give the guy credit for helping you out of a jam? interesting.

[hjl4]

you think it's not the adult thing to do to give the guy credit for helping you out of a jam? interesting.

I don't know how much help it is to just point you in a different direction. You still have to do all the work that gets you there. Tom's answer was wide open to many other possibilities.
Keep up the good work Ray, your almost home.

[GJeff]

Whew! Spent the last several days working hard on the servo driver. I've finally had a breakthrough, and it's now very nearly ready to go. The ended up tossing my entire trajectory planner, and instead going with a much simpler exponential approach. I also added velocity limiting, and now use different algorithms for long and short moves. The result is much faster positioning, and it deals with the backlash very nicely. I can go from any position to any other position in about 1/2 second, and end up within just a few encoder counts from the target - at the current 8192 counts/rev, that is MORE than close enough. The best part is the latest code requires significantly less CPU bandwidth, so I was able to go back to a 10mSec update rate. When I get a faster processor, I should be able to easily reduce that to 1mSec, for even better performance.

I also now think I will likely be able to come up with an "auto-tuning" algorithm", so the servo can be easily re-tuned periodically to compensate for wear, friction, etc.

I'll try to get a video up later today.

Simple is good. What chip are you using, and what one are you eyeballing to get to 1mS updates?

[SCzEngrgGroup]

Simple is good. What chip are you using, and what one are you eyeballing to get to 1mS updates?

Right now, I'm on a 16MHz Arduino. I think I might be able to get it down to about a 5 mSec update rate. There are many alternatives. One very attractive option is using an Altera FPGA, and using their NiOS soft-processor. It's good for at least 150MHz, and I believe now has optional floating point acceleration, which would make 1mSec easy. Even without the FP acclerator, it should be more than fast enough. In many ways, this is the most attractive option, as it would put most of the electronics into a single FPGA, and be almost infinitely configurable, even in the field. Other options are a TI TMS320 DSP (this would be, by far, the fastest option), and a 700MHz Raspberry Pi is attractive in some ways as well.

I don't know where I'll end up yet. This has proven a lot more challenging that I expected, but it is now converging on a very workable solution. Today I got homing very nearly working, and once that's perfected, the same code will be used to zero in on each toolholder position, as well zeroing the transfer arm to the spindle and carousel, using embedded sensors.

Regards,
Ray L.

[kvom]

Is the carousel rotation bi-directional? If so then obviously a tool position is a maximum of 3 moves rather than 7. Any idea of what will be the average tool to tool time?

I'm also wondering how you'll determine at power up which positions have tools installed and whether there is a tool in the spindle.

This is quite an interesting project, and your blog on the progress has been great.

[SCzEngrgGroup]

Is the carousel rotation bi-directional? If so then obviously a tool position is a maximum of 3 moves rather than 7. Any idea of what will be the average tool to tool time?

I'm also wondering how you'll determine at power up which positions have tools installed and whether there is a tool in the spindle.

This is quite an interesting project, and your blog on the progress has been great.

Yes, the carousel moves both directions, and always takes the shortest path from where it is to where it needs to be. On the final version, there will be a sensor that will indicate whether each "slot" is occupied or not. That feature is not yet on the prototype, as it will require re-working one part on each "tool receiver". Detecting a tool in the spindle is more problematic - the only way to detect it is if a "crash" occurs when attempting to move the arm past the spindle. The firmware will probably just assume no tool is loaded on power-up, and after that will keep track of whether a tool is loaded or not. If the user manually installs a tool, without informing the ATC, then a crash may result. I think this is a reasonable compromise, as even if the ATC can figure out a tool is there, it has no way of knowing what to do with it. However, a crash should be a harmless event.

Regards,
Ray L.

[GJeff]

Are you compiling with the default optimizations for size or did you jury rig Arduino to compile for speed?

[kvom]

What is the g-code sequence to park the spindle tool in the carousel without loading another? You'd want this at shutdown I assume, and also in normal production to load a tool via the PDB that's not normally stored in the carousel.