Monday, February 16, 2009
I have had my head down recently to wrap up the new electronics developed in conjunction with Bits from Bytes.
If ordered, this board is available with the new Version 3 Laser cut machine. We have tried to keep everything neat and compact. Ian has done a splendid job on the board layout, I have concentrated on porting the code to its new environment..
The board is shown without the OLED screen attached in the first image to show the PIC32 chip.
So, what does it do?
The answer is really quite simple, you plug in the stepper motors across the top, connect limit switches and a fan. The extruder connects via the header on the left. On power up, it reads the SD card and runs the print process. In the past I have given a few details of the SD card interface and how in conjunction with a joystick we are able to jog through the files on the card, pick the one you want and run the print.
The new firmware sends the machine “home” at the start of the print, hovers in a rest position while things warm up then proceeds to print the object in the centre of the table. Manual mode can interrupt the print at any time, the tool can be moved away from the printed object, when it comes out of manual it then returns to the print and continues the print from the next instruction.
The production board does not use a joystick but 6 buttons instead. The four in diamond format on the right do X & Y while the two just to the right of the SD socket do Z.
The final button on the board is used for switching modes, Auto/Manual.
Across the top of the board are 4 identical stepper controllers, the three to the right do XY&Z, the one on the left is something new, a stepper controller for the extruder. The V3 machine will ship with a new extruder design, a new screw-feed design but much more robust with machined spindle and bearing supported both ends. The drive is a stepper motor to give precise speed control.
Moving to the bottom of the board we have the SD socket on the left, moving right, the two Z buttons followed by three FET's we use to control the heater and cooling fan with one spare (AUX) for future use. To the right of the FET's we see an 8MHz crystal with the PIC32 below it. Next the XY buttons and voltage regulator and finally two sockets, 12VDC Power on top and USB below.
You can also see at the bottom of the board (below the XY buttons) a PICKit2 programming interface.
We have tried to make programming and update as simple as possible for all, the PIC32 can be programmed in several ways:
USB boot loader, used in conjunction with a small PC application. The PC software downloads HEX files straight onto the chip, no need for any programmer at all! Develop software in the free MPLAB IDE and flash the HEX file via USB.
PIC Kit2, the low cost programmer debugger from Microchip, the one I have cost £20 and it came with a low pin count development board.
ICD2/ICD3 Full programming /debugging facility direct to the chip
With this system we can distribute HEX updates for those that just want to flash the chip with new firmware, and for more adventurous types you can make it do what you want.
The G_Code interpreter is still pretty much the one I posted back last year, it reads a text file from the SD card and serves up steps in more or less real time. We have implemented a FIFO step buffer that takes the output from the Bresenham algorithm, the buffer is then read by an interrupt that fires at the required feed rate. Feed rate is adjusted to compensate for moves in both X&Y if they step at the same time.
The buffering also enables control functions of the extruder to happen in parallel, temperature control and extruder speed and fan control all happen in the background running off another interrupt.
The OLED screen is small but so useful for this application. Its fast, very fast compared to the LCD's I used before. This increase in performance lets us show the code line number, even the G_code text as the lines are processed from the card. We can also show the buffer status with a bar graph across the screen. With this you can observe that the buffer never “runs dry”, confirming real time operation. Another feature added to the screen is a file progress bar giving a graphical representation of how long there is to go.
Other information like tool type(pen, extruder, router etc) current file name, print status and error messages are also put out as appropriate.
As for the output of the machine, I have posted many pictures in the builders blog, the improvements in the print quality mainly down to improved control.
just wondering if i could take a look at the design files and source code for the interpreter.
i might have some made up as well to play around with.
any chance of changing the stepper headers to be compatible with the current RepRap stepper drivers?
I'm writing a g-code interpreter in C for the atmega168/Arduino with what seems like a similar interrupt driven buffered stepping strategy. You can find the details and source code at http://grbl.tumblr.com/
Where can I find the code for your interpreter? I can't seem to find the post you are referring to.
i really want to check out the schematics, as the picture doesn't quite cut it. do you have access to subversion?
i'm also wondering if it has support for endstops / etc. also, i'd love to peek at the code to see how it works.
The short answer to your question is yes, as much as C projetcs ever are.
I have used the Microchip MDD files system to look after the FAT system on the SD card and also to run the USB coms. You possibly use the same one on your PIC18 for USB communication, it covers the PIC18,24 and 32 chips. I have also used the Microchip HID USB bootloader. Both these librarys are available free of charge from the Microchip website.
Development work started on the Explorer16 board and has moved through three prototype configurations before the one shown above. For development work on the PIC32 there are several compilers you could use, visit the Microchip website and check out the Microchip PIC 32 development tools and software.
Sorry for sounding a bit like the Microchip Rep! For the record I dont have any association with them, but they do make it remarkably easy for developers by providing the MDLAB IDE and also many free software library files.
There is no need to change the headders, they are screw terminals to take the wires direct from the stepper motors. The driver chips are all on the PCB. There are no other boards or electronics required to run the machine. Stepper motors, axis limit switches (end stops?), cooling fans and the extruder all wire in direct.
Regarding your other question, you went to great lengths to explain to me why the RepRap community went away from Microchip (yet still uses the odd one!) Your main argument being that to use Microchip products were not open source enough, has this changed?
The main attraction of this new board is that it is a stand alone solution for the RepRap but has also been designed to cover other CNC Home and hobby aplications.
There are many who have an interest in the RepRap concept but who have no interest in electronic development, they just want to get on with mechanical development. This new board fills that gap, its literally plug and play.
It is simple to install and runs the machine without the PC connected. Software updates do not require any special programmer, just bootload a HEX file. I will maintain the software through any revisions in the short term, and distribute the new firmware ready to anybody who wants it.
The RapMan is a commercial product that has taken a long time to develop, I dont think it unreasonable to try and recover at least some of the financial investment we have made in the product, having said that as far as I am aware, the intension is to release source code, how we go about this and when we still need to sort out with Adrian.
We could do as you suggest and drop the HEX updates onto the SD card, but for now its USB boot loader, it works well and is very simple to use. We could also use the USB link to drop Print files on to the card. The chip is about half full on program space and 25% full on the Data RAM so there is loads of room to put in other stuff if that's what people want.
The PIC24 project was put on the site back in June or July, it may still be on the server, look under software and electronics.
i have no problem with anyone making money of reprap, completely the opposite. i wish you guys the best of luck.
the thing i care about is that it remains as open and as accessible as possible. you never did answer my questions about open source:
1. are the board designs open source?
2. is the firmware on the board open source?
3. is the lasercut design open source? (trick question: it has to be, as its a derivative of the Darwin design)
the thing about PIC chips is that in order to use them, i need a windows box. if i want to hack on your firmware (and I do!) then i'm pretty much screwed. dont underestimate the number of people who will want to modify your code.
It's amazing what you guys have done. A lot of work and you're offering a plug-and-play solution indeed. There's one big 'BUT': You should clearly state on the BitsFromBytes that you're using a closed source control system. I guess some will be okay with that, some won't. At least they should know about that.
I know that some people who think they are buying an 'open source' machine that can replicate most of its parts. This is not the case for this machine anymore. It cannot reproduce the parts since they are proprietary, as you seem to be saying. It can produce parts for a 'real RepRap', so calling it a RepStrap would be fine.
Don't be amazed if people will start writing their own firmware. It's a nice board to use but if you cannot adapt it to your needs, a lot of the hackability of the entire RepStrap is lost. People expect a machine that you can hack and adapt if they buy it under then name 'RepRap'.
I'd probably want to buy it if it wasn't closed source system. I have a PICkit 2 at home and more PIC experience than with AVR. Where I could I would've improved it and shared it with you (and everybody else).
I would greatly appreciate it if you would open-source your versions soon.
For me it would be more reason to buy from you (out of appreciation).
For others that care more about hackability, it would be a reason not to resort to the alternative open hardware that can be used to make a RepRap.
For you, it might be better if people experimented on your version and improved it, people that made the basis of your system more robust by applying it to situations you had not thought of.
For the result. The effect/driver mentioned above is a major reason why, for example, Linux is a powerful platform running on the most powerful super-computers and hundreds of millions of small device such as mobile phones).
Open value Creation and closed value capture? An unresolved contradiction?
I understand your position that you need to capture profits from your (substantial) efforts. It highlights an interesting dilemma of closed vs. open. I read this in Prahalad (2006, pp. 113-114): "collaboration to create value is commingled with competition to extract value."
Similar point of view is brought forward by Joel West: "no standardization activity that is economically self-supporting can be perfectly open: from an economic perspective, there are limits to openness" (West, 2006b)
Simcoe (2006) observes that in standardization, firms face an inherent conflict between value creation and value capture. A completely open standard creates lots of value, none of which can be captured; a completely closed standard captures 100 percent of no value created. So a profit-maximizing firm must seek an intermediate point that partially accomplishes both goals.
I hope you believe that I can understand your point of view. But I don't think it is really true what Simcoe says, that "completely open" implies "no value capture". If you're the favoured (respected) supplier for an open source product (you know you're product well since you play a key role in its development), you will always supply the latest revisions and you have most experience with selling and supporting it. In order to capture value, you resort to making it closed source. I'd say that to sustainably capture value you should make it open and stay ahead. You've already proven that you can produce a technically superior system. Yet the product is more than just 'what's in the box'. It is also:
1. perceived value (hackability, values of consumer that resonate with that of the makers)
2. sustainable value (will it be supported, developed by one person or an entire community).
I can only speak for myself, but reason 1 and 2 would make me choose a possibly 'technically inferior' system with (in my view) more potential (due to the way it's developed) and which corresponds more with my personal views. I like the idea that people from around the world, including myself, have put work in a product that I use. You talk about high development costs that have to be earned back. Those costs are sunk and you should look at the future. What is the best course of action for the future. The exact fact that you state, that doing all the development internally is expensive (and thus now you feel you need closedness and value capture to earn it back), is a reason to allow development work from the outside to improve your product. Sunk costs are mostly disregarded for emotional reasons. It is something that hurts business and increases rigidity in organizations (and reduces learning from mistakes). Just as the 'not invented here' syndrome is also hurting businesses. It's a solo-player mentality that is not sustainable in a world where others are teamplayers.
A thing I especially liked about the market that is emerging around RepRap and other open hardware is it's leadership in seeing innovation from the outside as valuable and something to nurture. A synergy between those that create value (who often capture admiration and non-financial benefits) and those that capture financial benefits who provide a platform in the ecosystem.
You seem to be stepping away from that model.
You've had enough to read, and it's to late here, so I'll leave it at this. I hope you find my thoughts interesting. They were meant as constructive critique, so please regard them as such. I'm interested in your reply, since I'm still playing with these thoughts as I read a mix of literature on innovation, open source, business networks and globalisation.
The other point I have to make is all our development of source code and PCB design is done using MPLab and Easy PC, MPLab is free to download from the Microchip web site but only runs on Windows I think, and is not open source itself. Easy PC is not free or open source, but neither is Eagle! I intend to provide PDF’s of the schematic and Board layout.
In the next week or two I will get together with Adrian to sort getting it all into SVN, but as always my time priority must go our customers who have paid money.
So to make it clear yes it is all open source, source code and board design but under the Creative Commons License for non-commercial use. It will all be uploaded and made available as soon as we are actually shipping the kits (next 2 weeks) I hope this keeps everyone happy, I'm sure I’ll hear if it doesn’t :-)
CC-NC seems like a good option!
Sorry if my answer was not clear, we think it is very important for people to have full access to both the board and the firmware, did you miss the following section?
“as far as I am aware, the intension is to release source code, how we go about this and when we still need to sort out with Adrian. “
Exactly how we do this is still up for grabs, Ian has some ideas mentioned above, but it will take us time to sort this out round the day job!
Thanks for your extended notes on the subject. I hope Ian's note clears up the issue of what we intend to do.
While we've apparently dodged the bullet this time, it's going to happen sooner or later. :-p
1. the openness of the design tools
2. the openness of the designs
For #1, its all personal preference. Some like to scrape by with open tools, some prefer to use closed. Either way is A-OK with me.
However, #2 is pretty big. Ever since the beginning (nearly 4 years now), RepRap has been 100% open. Adrian from the released all his designs under the GPL with the intent of making them completely free. Users should be free to do whatever they want with them, including selling them if they see fit. The only restriction is that if you improve it, you have to share it with everyone else under the same rules. This has been a primary attractor for many to the project.
Now, I love CC and such and I license all my photos on Flickr with them. However, I feel a bit slighted to see talk about walling off parts of the RepRap technology. The whole idea of restricting use as commercial/non-commercial seems fairly distasteful to me. I'm not even really sure what that means.
Can people use the designs to build things commercially?
If a business buys one and modifies it, does that void their license?
One last thing: the Darwin design is GPL, so any derivatives *must* be GPL. The electronics and firmware are completely new AFAIK, so thats obviously completely up to you guys. I'd just like to say that it would be a nice nod to the community to release your designs as openly as everyone else does. And if you're worried about someone 'stealing' your design and selling it, you shouldn't. I released the Sanguino as GPL and people have begun selling it in their stores... but they come through me to order their kits for resale. It's definitely a win/win situation, IMHO. More freedom, more better.
To quote from the GPL FAQ: "The GPL does not require you to release your modified version. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
"But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users, under the GPL.
"Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you."
My gut feeling is that it isn't. I expect the legal precedents here in the States will hark back to the cases of the companies that reverse engineered the old IBM PC bios.
The courts ruled in those cases, iirc, that the reverse engineered bios chips weren't derivative if they started with the performance function of the IBM bios and built up equivalent code to do the same thing. This is not the same thing, mind, of disassembling code and going from there. That's cheating from a legal point of view.
Doesn't sound like to me like tofletcher and Ian are headed in that direction. Sooner or later, however, somebody will.
I really like the idea of the plug in SD cards, it will make printing become a much simpler system for use by people who aren't hackers.
I know that the new sanguino motherboards haven't even been produced yet, but I will say that this type of board design is the way to go for the general electronics. I'm expecting that within a month or two, a board that works like this could be developed that is simply the current motherboard, but made larger so that the stepper boards are integrated.Maybe another month for kits to be made. Maybe with one part for the cartesian bot, and another for the extruder (so you can attach it to the carriage easier).
About the board: I'd say that since this is written from scratch (which is not the sole criterea) it would be okay to licence it with whatever they like (CC non-commercial for example). I think the discussion has shifted to the cartesian bot and other parts of the BfB RepRap that are clearly derived. They're not allowed to license a GPL'd design or a derivative of it under any licence than GPL.
That's at the heart of the GPL. You can do pretty much anything other than take away people's freedom to do pretty much anything with it.
I think their intentions are clear and understandable. But making a GPL licensed work CC-NC would require the consent of all contributors (at least). For this pretty plug and play control board it's fine, for the Darwin based design it's not possible.
It is my understanding that, since the GPL is a license that bases it's power on copyright, it is only capable of governing actions related to the digital file itself - not a representation of that file in any other form. In other words, I could modify the GPL'd Eagle file for Zach's Sanguino, produce boards based on that file, and distribute them - all without being required to release my changes. Distribution of the modified file, however, qould require me to make my changes available.
Does this fly in the face of the intent of the GPL? I think so, yes. But it's the way the law in the US is structured (again, my understanding). So by all means, we should talk about the liberal licensing of the files surrounding the RepRap project, and _strongly_ encourage others to make their changes to said files public, but the GPL is a _highly imperfect_ license for hardware, and as such, there are some very murky depths surrounding it's use in this way, that will require a court or a further license revision to explore more fully.
So to review... The GPL is a _copyright_ license. Text, audio, video, and many other things are subject to copyright laws, but _things_ are not (in the US).
To restrict the (re)distribution of a physical object in the US, you'd either have to convince a court that the physical object was a derivative of your digital (copyrighted) file - with ridiculously far reaching implications across all industries, exploit contract law through a modification of the GPL, or some other license (this is common practice - though hard to enforce on a broad scale), or exploit patent law somehow (expensive, and equally hard to enforce on a broad scale).
Of course, this is simply a snapshot of my (imperfect) understanding, I am not a lawyer, and none of this is to be construed in any way for legal advice. If you have any questions - or even if you don't - talk to a lawyer.
IMO, the whole strength of the Reprap concept lies in the fact that it can, in theory at least, be easily replicated by relatively unskilled people. As long as we continue to strive to keep the vitamin content of Reprap technology both small and relatively unsophisticated, I doubt we'll go too far wrong.
Personally, I really buy into the notion of putting the technological means of production directly in the hands of the proletariat. If we can manage to do that, I think we will touch off a firestorm of innovation such as the world has never seen and that traditional commercial firms will be entirely incapable of keeping up with. I really like that idea.
Anyway. Like Forrest, I am not really interested in these deontological distinctions. In practice, Ian put all the files from his last design in the repository, and I have no reason to suppose he won't with this one too. It's just that he (and I) have both been a bit busy, and so haven't had a chance to discuss and to arrange it.
I have been following this one for a little and am a touch concerned.
All credit is due to Ian & tofletcher for their implementation.
If the code in their implementation is 100% their own (some may have been C source from the current, but in reality I don't actually really know) and it is the intention to release it as a limited licence (ie not for commercial use) I think we need a clear statement that is the case and it should ideally be published from Bits from Bytes under that limited licence rather than in the RepRap repository. (which would be very confusing for the uninitiated).
Particularly as there will inevitably be other folk who like Ian will choose at some point to produce commercial enterprises or product steming from the RepRap project and should be as free to do so as Ian has been......
If we allow the two very different licensing models to be muddled together, the situation will inevitably arise where there is conflict over who has control over what. Particularly as money will be at stake.
I guess it goes without saying that if Ian and tofletcher have reused sections of the current projects source then their own implementation must by definition also be made available under the terms of the licence that they acquired the code under. ie GPL or CC or whatever.
For me it is either GPL and part of the project, or not GPL not part of the project and housed/made available separately but may be referenced as an alternative.
Thoughts for what they are worth....
As far as I'm concerned the very best feature in this board is the standalone printing from SD. It is wasteful and inconvenient, most of the time, to direct-drive a RepRap-like machine from a whole PC. If RRRF makes a control board that will do standalone printing while maintaining the modularity and open-sourceness of the design, Ian may well sell a few of his kits without electronics -- and there's nothing wrong with that. The interface this particular board provides is to 4 steppers and a variety of heater controls and such. That could already be easily replaced by current Version 2 electronics.
We do need a new platform, though. Even Sanguino is severely hampered by the limitations of AVR8. Whether the new platform should be AVR32 or PIC32 is more a matter of taste.
You have though I feel missed the point re licensing.
The RepRap Project is very much Open Source/GPL/CC.
As such it is wholly appropriate that anyone uses it for what ever they want including, but not limited to commercial gain.
Key phrase here being "anyone".
With the proviso that the resources so used are used with the for knowledge of their licence and terms.
ie You can use this to make as many commercial products as you wish (make as much money of it as you wish) but it remains open source/GPL/CC, ie you may not prevent others from doing the same.
Its a bit like saying you can have as many ladders as you wish but you may not pull them up after yourself and/or deny others their use.
Many people have given their input to this project freely and enabled those who wish to to gain fiscally from that to do so. (as it should be)
Those who gain though may not refuse others the same rights. Nor may they take the freely given resources and fence of the next steps as it were in the projects natural direction. (especially not using that freely given resource as part of that solution).
If it is good and open for one, it is equally good and open for all.
We are currently in rather grave peril of ending up in, "All animals are equal but some are more equal than others" territory. (George Orwell, Animal Farm)
Personally I don't see that either RRRF or Bits for Bytes (or anyone else who fancys making some money of what ever magnitude) will be commercially incapacitated in any way by complying with the licensing of the project as it currently stands.
On the flip side though I can see that the project would be intellectually incapacitated by allowing commercial exploitation to annexe or control the projects direction.
There is an argument that having got a product to market, this is indeed a useful protectionist strategy.
This is a common and recurrent cross roads that all open source projects come to once they have spawned commercially viable products. Where there is money in it the fight as to who can grab the biggest share ensues.
Probably comes across as a little strong but should clearly make the point.
I'm operating under the assumption that the electronics board is independently produced and does not use any hardware or software items from the RepRap project as such. It doesn't (superficially) look like anything was reused.
As such, it is neither legally nor morally necessary for the electronics board to be open source at all, let alone GPLed. Regardless of whether it happens to perform a similar function as a board that *is* open source.
If the software and PCB designs do go out under CC-noncommercial, that is entirely the author's choice. It'll make it a lot easier to determine if there is in fact code reuse from GPLed items, and if there is, *then* we can talk infringement.
As it is, this electronics package does *not* appear to me to be one which should automatically be GPLed just because the project it's designed to interface with is, any more than the nonfree packages on linux are.
Again we are largely in agreement. The hardware is correctly speaking largely irrelevant to this discussion as you have highlighted. (Although I am sure someone may wish to argue otherwise, I think this is CC & Attribution anyway but could be wrong)
The question remains over the Firmware and it's provenance...
If 100% Clean Room development ie no source has been used from the RepRap project no issue arises. (I think I made this point earlier)
If however the firmware is'nt 100% Clean Room ie it is built (quite sensibly in my opinion) on the source already available that does whole bunches of what is required to run a RepRap style machine then the licensing under GPL is quite specific.
Remember that a whole bunch of the host is Java and the Arduino/Sanguino code is thinly disguised C. Making it all wonderfully portable. (An asset to all who want to use it's magnificence)
The principle has been tested and the precedent has been set, through a range of larger commercial organisations who have used open source (Linux Kernels etc) in their embeded products (eg Linksys Routers, amongst others) and then been found out.
Given that this is a PIC32 rather than an AVR8 or PIC16/18 family board, I'd be surprised if much of the RepRap code even was usable for them, and I'd be more surprised if they used it directly in any sense. Going from Gcode to stepper movements is not rocket science, and would mostly need to be tuned to the actual hardware extensively anyway. But yes, once we have the code we should certainly run diffs and check -- but I trust that the outcome will be negative.
The source code for the PIC32 solution has not been published to date. If it shares any source code from the core solution I, for one, will be very surprised. The PIC32 is by definition a 32 bit processor, a long way different from the one used by the core development and I can honestly say that I have never even looked at the Arduino/Sanguino code, why would I, it runs from a PC in a completely different way to mine.
I have posted in detail some of the strategies used in my code so these may or may not have been adopted, if they were then I am glad it was of help, its the reason I posted it! Having said that, I have not provided source for the core and I have not used any of theirs.
I have used a version of the Bresenham algorithm taken from the internet and adapted for my application, this was not in the form of working source code but pseudo code demonstrating the general principle. I have also used Microchips MDD file library for FAT 32 implementation and USB coms, both these are made freely available from Microchip with the proviso that I do not distribute their source code and it is not ported to another manufacture of microcontroller. I agreed to those terms when I downloaded the files. When we post our source code it will not include the MDD file system, they are not in my gift. If you want them you are free to download them from Microchip and agree to the same licence I did when I chose to use their code.
With the adoption of G_Code the RepRap is now a fully fledged member of the CNC home and hobby community, the thing that makes it different is the extruder and the design concept of being self replicating.
My software was originally developed to run the RepRap bot. as a CNC router for PCB production. I only used a RepRap frame as this was a very cost effective CNC platform. Having created a working PCB router, Ian (BfB) asked me if I could put the Extruder command set into the interpreter. This was reasonably straightforward as the extruder uses and extended set of modal commands. These were tagged onto the end of the interpreter.
The G_Code interpreter as an idea is as old as the hills, there have been dozens of PC versions and quite a few microcontroller solutions, so both our bot control solutions are hardly unique in what they seek to do.
My solution is a very basic interpreter with one additional module that is switched in to run the extruder, the rest is fluff to make the screen and support electronics run with it.
The single board solution can run a RepRap, but just as important, it can run many other stepper driven CNC machines all currently hogging the parallel port of a PC. In the short term I would prefer not to be selling this board into a market against my own design repackaged by others. But we think that it should be available for people who buy the board (or full kit).
I would also say that no final decision has been made on licence, we need to tie up with Adrian at some stage and sort out the best way to do it.
I hope this answers a few of the question.
Using Creative Commons Non-Commercial means that it is _not_ Open Source and _not_ Free Software.
Leaving legalese and copyright law out of this, CC-NC is explicitly against one of the major points of both Open Source and Free Software: You are not allowed to discriminate against persons, groups or field of endeavor. I.e. Discriminating against commercial use means it's against both the letter and the intention of Open Source.
Making source code available for people to peek at or change for personal purposes is something else and must never be called Open Source.
Also, as Tony points out, since the BfB firmware is based on proprietary firmware libraries, it will probably be hard to make the firmware Open Source.
This, combined with the minimal Open Source community around the PIC microcontrollers and the locked-in development environment, is one of the main reasons I've been moving towards AVR controllers.
That said, having this PIC board as a commercially available product is a great thing for people wanting to have a RepRap machine but not participate in core electronics or firmware development. It should, IMO, just be made explicit that this is not Open Source, and by extension, not part of the RepRap project itself.
Incidentally, as far as I know, simply relying on commercial libraries doesn't in any way make it impossible to make source code either open source *or* Open Source -- it just makes it a lot harder to compile said source. The requirements, however, go only the other way. You have to provide said source with a compiled version, but you don't have to provide a compiled version along with the source.
Links to this post: