Possible fix of comms delay bug

Last I heard, both the SNAP-based and Gcode-based host/firmware pairs were exhibiting the line-segment-pause bug, which leads to brief pauses between segments and a buildup of plastic where it shouldn't be.

From another thread:

Forrest Higgs Wrote:
-------------------------------------------------------

> Well, that's the theory. In my own experience,
> however, without a serious data buffer in the
> comms path, you are going to be very chary about
> doing anything on a PC that might cause it to hang
> or even hesitate in the middle of a multi-hour
> print. I don't know about Linux, but Windows
> regularly causes hesitations on output ports just
> by itself and for sure can easily cause them when
> you have a background job running and then do
> something serious in foreground.

Now recently, I've been looking into EMC2, the excellent and free Linux-based CAM software [www.linuxcnc.org]. I plan on using it to control my CNC-mill based RepStrap. What is interesting about this software is that it doesn't run on Windows, or even on a vanilla distribution of Linux. There is a very good reason for this - the program requires a patch to the Linux kernel that transforms it into a "real time operating system," a system that guarantees that high-priority processes will have their requests fulfilled within a defined (very short) time interval.

Now, Windows and normal Linux distributions don't use this system because it leads to a less efficient environment for everyday tasks, where there is generally no significant drawback if your high-priority task has to wait a few milliseconds while the CPU finishes up a less important one it had already started. However, this concept may be just the thing we need to squash this bug.

The other alternative is to put in a comms buffer somewhere between the computer and the printer, as Forrest is doing with his EEPROM chips. That is probably the easier and cheaper solution (from a user's perspective) in the long run, as it allows for the possibility of a user to use their standard Linux or Windows boxes unmodified. However, I think it would be very interesting to check whether installing the RTOS kernel patch will fix the problem by itself. Thoughts? Anyone running a printer on Linux willing to try? If the problem lies primarily with the operating system (as opposed to the host software or drive electronics) this simple fix should noticeably improve print quality.

The rep rap host uses java. The JVM will periodically run garbage collection, some minor, some major. Major collections (there's probably a better term for this, but I'm too lazy to look it up right now) will cause a noticable pause during a big and complicated build... this can be up to a second or two.

Don't use Java if you want to avoid this sort of thing. I couldn't tell you how other implementations do (can skeinforge talk directly to a reprap?), but you can profile the Java host software and see for yourself the ever extending garbage collection delays. I suspect a major culprit is the little 3d progress window.

The bit of code which talks to the reprap should probably be written in something that doesn't have any 'magic' going on behind the scenes. C is traditional though I'm sure most things will suffice if you understand them well enough. It probably also shouldn't have a GUI. A hardware driver that runs in the kernel is of course the usualy way to do this, but this is a) potentially quite complex and b) very operating system dependant.

Real time operating system extensions aren't a silver bullet that will just make problems vanish... you have to write your code to make use of them. And this is something that requires a certain amount of low-level code, which again will probably require something like C or C++.

Extra hardware may well alleviate this somewhat. Big buffers also move us closer to the point where a reprap could run untethered from a PC. But it adds yet another layer of complexity and expense to building a reprap, which a software solution (once implemented) would not.

Sheesh, FUD time again I see. The minor garbage collections are only a couple of microseconds long, so they don't count. The major collections can take a couple of seconds. If this is problematic you give the jvm this option: -XX:-UseConcMarkSweepGC and the problem goes away. It uses a bit more cpu which is why it isn't enabled by default. Next time read the Java manuals before spouting garbage.

--Blerik

The reason EMC needs the Real Time Kernel is that it is directly pulsing the steppers. If it was simply providing a stream of motion data that was interpreted later it wouldn't need the RT stuff. Of course, it also wouldn't be able to do all the cool stuff it does...

The software needs to be specially written to access the RT stuff too, so simply running the "normal" host on a RT kernel would probably do nothing but make it worse off. (I think.)

Ah, ok. Well, it was just a thought.

Quote

Sheesh, FUD time again I see. The minor garbage collections are only a couple of microseconds long, so they don't count. The major collections can take a couple of seconds. If this is problematic you give the jvm this option: -XX:-UseConcMarkSweepGC and the problem goes away. It uses a bit more cpu which is why it isn't enabled by default. Next time read the Java manuals before spouting garbage.

Thankyou for your well considered response. I'll confess I wasn't aware of that particular fix.

Nonetheless: major collections *are* a problem, have been a problem and will continue to be a problem until everyone is aware of this little fix or they are avoided in another way. So perhaps a little civility and a request to have it put somewhere sensible on the website might be in order.

Quote

The reason EMC needs the Real Time Kernel is that it is directly pulsing the steppers. If it was simply providing a stream of motion data that was interpreted later it wouldn't need the RT stuff. Of course, it also wouldn't be able to do all the cool stuff it does...

There is that, yes. I recall Ian from bitsfrombytes was talking about selling control boards that would let you drive a reprap from a parallel port which would be interesting; but as no electronics have been forthcoming I guess he's been far to busy to continue with that little project.

The most important thing that real time guarantees give is the ability to *respond*. But if all the feedback loops are handled by the hardware (extruder shaft encoder is the only thing I can think of offhand) there's be no great need for RT stuff really.

The whole point of having a microcontroller is to avoid the PC having to do realtime stuff.

The easiest fix I think is to add a buffer to store a at least few seconds of data. I believe the Arduino has an SPI port so just stick an SD card on it and the problem is solved.

With my machine I use Python which doesn't seem to have any GC delays. I use 100MB Ethernet so I have no comms delays. It all works well unless Windows decides to go away for a few seconds. E.g. when plugging in a new USB device. If I dedicate a PC to just driving the machine I have no problems, but I will add an SD card buffer so that I don't have to dedicate a PC, and in fact won't have to even have it switched on since I will be able to buffer many objects worth of data.

As an aside: I tried driving my machine via WiFi. Even though it is 54Mb and full signal strength it had noticeable pauses and produced defects like you see on objects from RepRaps.

---

[www.hydraraptor.blogspot.com]

I used to control my steppers direct from the parallel port, using a python module written in C, but then I switched to the generation 1 electronics. It worked pretty well without a realtime kernel but my machine wasn't capable of much then so its hard to tell how effective it was.