Of course I am very sad that you are disappointed. You purchased a Polarshield, with an LCD and some motor drivers. It was built to order, tested and seen to work, packaged and shipped in good faith, and you have every right to expect it to work when you received it.

Would you like to be part of the solution? You can be, you know: Read on.

- Which bugs have you experienced in v1.10 (released 2nd Aug 2014) that you believe to have been fixed since? The issue number would be great (refer to https://github.com/euphy/polargraph_server_polarshield/issues?q=is%3Aissue+is%3Aclosed for a list of closed issues).
- Which blog reports the static error screen? What do you mean by "error screen"? Any chance you could send me a little picture of it so we're not just guessing?
- I'm not sure I understand your sentence: You are able to run the compiled version? Or only run from source through Processing? All versions are compiled from Processing: It is a Processing application. The controller software is sometimes a bit awkward to get running, you are correct. I am really glad you got it running though: I think you have solved your own problem - which is always satisfying.

The bare Polarshield is sold with something of a caveat stated clearly on the product page, I'll excerpt it here:

An assembled board is tested before shipping, but the builder accepts all responsibility for getting it working. There's a limit to how usefully I can troubleshoot issues without seeing the board in front of me too.

(http://polargraph.bigcartel.com/product/polarshield)

I can build it and test it, but I have no idea what you might plug it into. While I am pleased to work with customers to help them solve their issues (mostly teething problems), it takes an investment of good will and good faith on both sides to achieve this.

The controller software is entirely open source and is available and usable even without Polargraph hardware. I recommend to all potential customers that they download it, try it out, make sure they are happy with it before purchasing.

sn

Ok, thanks for your reply and your insightful suggestion of writing software that works. Bluntly put, and correct. So:

- The touchscreen only works for you with precompiled hex v1.10.

This is an extremely good point. I intended to package this version with the polargraphcontroller code bundle. Somewhere along the way I guess I got a bit excited and updated the version in the code bundle to be the head of master. Since v1.10 there have been zero bug fixes, but potentially many bugs added. All recent Polargraph machines have shipped with v1.10 on board.

That said, I have just committed a change to polargraph_server_polarshield (https://github.com/euphy/polargraph_server_polarshield/releases/tag/v1.2.1) that fixes an extremely obvious problem with the LCD: #USE_LCD was commented out.

Please accept my apologies for that - that version should not have been included in the code bundle in retrospect. I have just put proper tags on the polagraph_server_polarshield repo too actually, should make it a bit easier to find things. And updated the hex and the source files to v1.2.1. I'll update the big code bundle tonight when I'm somewhere warmer.

One thing I noticed: Arduino IDE v1.6.6 appears to have broken the code again. This is frustrating, but it compiles fine in Arduino IDE v1.6.5. I'll try to have a dig to see what's happened in the new version.

- The precompiled (executable) controller doesn't work for you at all.

It might sound like passing the buck, but I believe Processing itself is at the heart of quite a few problems that Processing users have. It's a slightly weird system, constantly broken in some small way, and is a layer of indirection on top of an already complicated Java landscape. It's just hard to work with.

I believe compiled Processing apps are not really suitable for distribution - there's just too much variance out in the world, and because they're Java wrapped in Processing, errors are swallowed up and it's very difficult to get useful debug information out.

However, if you've got it running from source - then you have solved your problem. Genuinely. If you can run it from source, then you do not need to run the compiled version. If you must have the executable, export the application from Processing yourself.

The executables are made available as an addition to the source. This is a source package, distributed with compiled executables, NOT a executable package distributed with source. If the executable works for a user: Great. If not, do what you would have had to do anyway, and run it from source, in Processing.

~

The controller is freely available to try before buying a Polarshield - you were entirely capable of evaluating the quality of the code, and free to make a choice based on your experiences. In fact, you had the device in your hand, having already received a refund, with an option to return it and have me pay for all shipping, and even then did not test it or ask for assistance.

I take this stuff seriously - I really do. This isn't my livelihood exactly, but it pays for itself, a workshop space, and it's very important to me. The community built up here is amazing to me, and so gratifying. I see people struggling, becoming experts and then teaching me something. It's a big part of my life, this is why I'm here now, taken a morning off my day-job to type up this response. This post has cost me more money than I could ever make from one sale (now refunded) of one Polarshield.

I have known for some time that I run a massive risk of disappointment - because anyone can just buy something of mine, break it, or just be having a bad day, and then splash all over the internet that I've caused it somehow, their lives are ruined. These are also very technical devices that require a lot from their users. Which is why I have such a flexible support / returns / refunds policy (er well, also the law). I expect problems to come to me personally, in good faith, with the expectation that I can help solve them, or at least make restitution as an individual, or as a company.

sn

The language is certainly a barrier, but your English is a lot better than my Spanish, so I can't criticise!

Where do you see in the Polarshield description that indicates it is _not_ supplied "as is"?

I can't compare myself to the commercial might of Makerbot. I don't expect to deliver the same standard of customer service as they do (jammed extruders notwithstanding). They are a high-price, high-commitment brand. They sell thousands and thousands of items, and have a well-financed customer support structure.

The reprap community is truly massive. Tens of thousands of people and maintainers. Just look at the site. The software output is so fragmented that I'm surprised you indicate Reprap as an example of well produced, well communicated software publishing. It is many, many things, but straight-forward is not one of them.

It is flattering that you think that I am able to compete with these two behemoths, but it simply is not the case. If you bought from the Polargraph shop, believing that you were going to be supported by a multi-million Euro operation, I am sorry you were disappointed.

It is very good that you pushed me into looking a bit more closely at the polargraph_server_polarshield firmware, because I spotted a genuine problem there, and have since fixed it, and tested the updated code. Thank you very much for that.

There is a new code bundle available: https://github.com/euphy/polargraphcontroller/releases/tag/2015-11-10-23-07 which includes the following changes:

polargraphcontroller 2.1.1
Fixed: The fit-machine-to-window sometimes backfires, and ends up with a negative machine size. There is now something to catch that.
Updated: Set default motor setup to be like PolargraphSD (200 steps / 8x stepMultiplier).

polargraph_server_polarshield 1.2.2
Fixed: euphy/polargraph_server_polarshield#8: Pen width is no longer "nan" after startup. This was an EEPROM loading issue.
Updated: Visibility of "calibrate" button can be controlled by a boolean. More suitable for general consumption.
Fixed: Uncommented #USE_LCD so ... it uses the LCD touch. This might have caused a lot of problems, so thanks to Erea for harrassing me into looking more closely at it.
Discovered: Doesn't work in Arduino IDE 1.6.6 (BOO!). DOES work in 1.6.5.