RepRap with XMOS

[Interactive_Matter]

No problem Folknology,

I think we are working on the same problem, just starting at different ends ;)
I still don't know if it will be XC-2 or XC-1 compatible. But most probably both. I think I will use the modular approach of the current projects on github. So that you got some serial communication module (for XC-1 and compatibility with current reprap PC software) - still undecided. Separated from that you will get the G-Code interpretation and separated from that the motion control.
I will first build a working tradtional reprap and reprap electronics. Then I will finish the TMC260 Library for Arduino and then port everything to XMOS.
It will most probably no the last time we discussed this ;)

Regarding the Trinamic drivers I really want to exploit two features of the drivers:

• The coolStep to reduce the power consumption.
• The stallguard to get away without endstops. It is a load measurement system. So it is very easy to detect when it cannot move any further. So it would be enough to have physical barriers instead of proper endstops. And you can calibrate the reprap more easily.

At least this is theplan. Let's hope that it will happen like this.

[dan]

Hi,

So this topic is about my thoughts and findings about driving stepper motors with XMOS (And to give my discussion with folknology a more permanent home.

Well to contribute to that discussion I'd start here:

https://github.com/xcore/sw_basic_motor_examples

Were you already aware of the existence of that project? It has multiple axes of stepper with microstepping, chopping etc.

Also I'd add that we are developing more flavours of PWM driver components which can utilise the 8 and 16 bit ports instead of 1 bit ports (which means we can cram up to 4 stepper axes on an L1). You probably knew that as well though.

So I'm wondering what really is the special sauce of that Trinamic driver for this project compared to what you could do natively? Is it just an ease of use matter?

- Dan

[Interactive_Matter]

Hi Dan,

thanks for the hint. Yes I was aware that the project exists. But I was not aware what is in this project.

I want to use the Trinamic chips for several reason:

• Ease of use. I know how they work and their features. And I like them. So this should be easy to do. I really do not have the slightest clue of motor driving and do not feel to have the time to study that too.
• The trinamic drivers offer a lot of features out of the box that would probably take a long time to develop. So instead of using a 5€ XMOS whith heaps of preogramming I will use a 5€ Trinamic chip.
• I want to use them. To be honest I have some business relations with them and I do not know if it is a good idea to also engage in competing technologies. But perhaps that is also true for XMOS - perhaps you want to push your motor solution instead of supporting solutions based on trinamics drivers. Don't know - an as long as I do not do, I stick to reason 1 ;)
• I am more interested in the application level. To be honest I hope a bit that Folknology will contribute on the lower level stuff, so that our both ideas can be combined. From a technical point of view his project(s) is far more ambitious. Respect for that. I hope by using this approach we both can keep the complexity a bit lower for each of us.

Thos are the reasons. I hope they are understandable. Since the project is in its very early stage I do not really know whe I will able to show the first results.
Let's see how it evolves.

Marcus

[dan]

Marcus - that's what I figured you'd say. Actually I'm not really advocating the XMOS stepper drive stuff for your project, more to just check you are aware of what's there now.

[Interactive_Matter]

Hi Dan,

I have quickly checked the source code. I did find some stepper driver. But I did not find any kind of motion control (acceleration/decelration/ axis coordination). Is that correct or did I jus not look good enough?
Since that will be one of the most important building blocks of an reprap.

I think the solution is a promising beginning.

Thanks

Marcus

[dan]

That's right - its just the drive.

As yet we have nothing out there in terms of XMOS or XCore IP for motion control, which is why we're all really interested in what you two are doing.

[Folknology]

Hi Dan I did actually link to the Xcore examples earlier in the thread and have already had a good poke around, although my approach is a hybrid one so varies in a number of ways.

Yes I will be tackling acceleration and even more ambitious things such as arcs, both of which should work with my drivers, the Xcore examples and even the Trinamic drivers. I am hoping this can be done at a high level but obviously each driver might exhibit somewhat different dynamic features underneath, hopefully a good abstraction can be found for the whole family based around channel controls/interfaces.

regards
Al

[Interactive_Matter]

…
Yes I will be tackling acceleration and even more ambitious things such as arcs, both of which should work with my drivers, the Xcore examples and even the Trinamic drivers. I am hoping this can be done at a high level but obviously each driver might exhibit somewhat different dynamic features underneath, hopefully a good abstraction can be found for the whole family based around channel controls/interfaces.
…

Hi Folknology. Good to hear that you want to tackle those problems. Let's see how this contributes to the RepRap idea (I think it will help a lot). You probably have seen that there is already ome useful stuff in the Reprap Marlin Firmware: For Arcs & Stepper Acceleration.
Unfortunately in GPL, not MIT or BSD License. I think this can be a usable start.

Regarding the compatibility I think (hope?) this will be no real problem. I think the motion will be controlled by some application specific values (max accleleration, max speed, step resolution). The specific values will most probably be defined by the mechanical construction and the specific motor (type). Those constants will most probably be configured from the application in the motion control. By this I think that the motion control can be quite motor & driver independent. So that you can swap driver and/or motor type. This would attach different drivers to the motion control and change the constants in the application.

From what I see there can be a modular approach which helps us to collaborate and end up in a quite flexible motion control.

Marcus

[Folknology]

Yeah we started using Sprinter which is very popular and moved to the more feature rich Marlin for our RepRaps. Marlin is probably better written than sprinter and seems to have a bigger future although the code base is less mature on RepRap (it has a grbl inheritance). There will also be some issues in porting it onto XS1 and we may well have to change significant portions of the advanced features to make them suitable for deterministic Xmos execution.

regards
Al

[leon_heller]

RepRap is attracting some interest on the Parallax forum, as well:

http://forums.parallax.com/showthread.p ... c%E2%80%A6

It might make sense for both projects to use common driver hardware.