What’s next, a teaser
I think I've arrived at a stage where I can show a bit of what I'm, working on, both as a teaser, and as a commitment for my self to make the teaser a reality ...
So, after several hours teaching myself Solidworks, I can show off the following image:
Working-name for the project: OpenCoreBot, or OCB. More details to follow when I'm closing on completion of the design.
CoreXY experimentation update #2: conventional revised belt path
After reviewing the naive errors in my thinking (see previous post), I've concluded that my idea for simplifying the belt path will not work. So, a revised prototype has been built, now using 3D-printed belt idlers on the loops, and only straight & symmetric lines on the essential parts of the belt path.
So, I'm no longer chasing the not-crossing belt path, instead going with a conventional, two-level CoreXY. There is now a crossing path on the belts, but the belts run on two separate levels, so there is no parts where the belt is forced to move in ways it's not designed to do.
Flaws in my simplified CoreXY idea
After building my first prototype of a CoreXY based cartesian movement system, as shown in two earlier posts ((CoreXY Experimentation))((CoreXY experimentation update)), I have realized that my idea for a simpler pulley configuration is flawed. I've simply forgot basic geometry math. The idea was to start with a CoreXY system, as described on http://corexy.com, take inspiration from FABtotum to avoid crossing belts, and simplify the pulley location to get as few anchor poins for the belts as possible. My attempt used two "layers" of belt paths, and tried to reduce the number of pulley-axles to 4, compared to CoreXY's 8 and FABtotum's 6. But, unless I start offsetting the location of stepper motors (and introducing uneven stress on the frame), I end up with an undesired geometry...
WordPress XMLRPC is a liability
This week I re-launched my blog, and I really wanted to do so silently, without the useless "Oh look, I've upgraded" type of post that so many publish (including myself in the past). But I was hit by a very common abuse-vector that prompts me to write a few words about it. The problem: DoS via WordPress XMLRPC. I've installed WordPress 4.0, a version where flaws in the XML-RPC mechanisms allowing it to be used as part of bot-nets and the like are supposedly resolved. But, after having my new WP installation active for less than 24 hours, my server ground to a halt, with ridiculous load numbers (190+ load), all caused by accesses to /xmlrpc.php
What is XML-RPC anyway?
The XML-RPC API is used by WordPress for a few things. The useful part, is making third-party publishing and administration applications for both desktop and mobile. But it is also used for so-called "pingbacks" and "trackbacks", where WordPress itself notifies other WordPress installations that links to their content has been created in articles/posts/pages. As this mechanism is supposed to run without user intervention, it's done without authentication, unlike the third-party client enabling admin/publish features of the API.
Insecure by default
Before WordPress 3.5, the XML-RPC API was something you had to actively enable. So to be able to use the API for publishing clients and/or pingbacks and trackbacks, you had to be aware of that the API existed, and enable it. For a number of reasons, I think that was a really good idea. Perhaps primarily because the XML-RPC used to have some seriously big flaws that could be used as vectors for abusing a WordPress installation. Now, from version 3.5, most of these flaws have been fixed. And with that, someone decided that users of WordPress are not very bright, and having to enable an API before using a third-party client was very complex and too hard for the users to understand. So they enabled the API by default. And removed the option for turning it off easily! How can possibly having an open API for anonymous, un-authenticated generator of HTTP-requests enabled by default, with no filtering, be a bad idea, right?
CoreXY experimentation update: pen plotting with motor moves
The prototype for my CoreXY experiment now moves by motor control. Using Marlin software on an Arduino Mega with RAMPS1.4 to drive the motors, I go through several speeds from 800mm/min to 24000mm/min, (that's 400mm/sec) moves. I have made no care to precision in the belt, and adding that to unevenly tightened belts, flex in components, and finally a pen that's not really fastened well, there is noticeable flaws in the resulting drawing. However, this also means the prototype highlights what areas of a final build will need extra attention.
Relevant links: http://corexy.com http://reprap.org/wiki/RAMPS_1.4 https://github.com/ErikZalm/Marlin
CoreXY experimentation
Based on the CoreXY concept and ideas from FABtotum to avoid crossing belts, I'm experimenting to see if I can get away with as few mounting-points for belts/pulleys as possible. This video shows that my prototype moves, as well as showing the CoreXY movements. Moving resistance feels very low, even if this is very simply built (no linear rollers/brass bearings, no attention made to precicion...). Next step: moving the parts using the motors 🙂
Ideas from: http://corexy.com/ http://www.fabtotum.com/ http://reprap.org/