@kongorilla: thanks, will check it out!
awesome things you've been doing!
↧
Re: How to create good vector data from straight (pixel) lines
↧
Re: How to create good vector data from straight (pixel) lines
WinTopo works perfectly for thin lined raster images. thanks *a lot*!!
↧
↧
Death 2 Sharpie 1st go
After playing around with the brilliant Death To Sharpie sketch by DullBits (thanks for the pointer to that, Sandy) and finally getting my Polargraph going again with Sandy's most excellent help, I've finally managed to produce some actual, on yer-dead-tree drawings!
I took B&W photos, resized to be approximately 1000px on the long edge, adjusted contrast and then ran through the Death To Sharpie sketch (much parameter enfiddlement ensued). I then did the Gcode import into v1.2 of the controller, and drew the output on A2 using Tombow pens (which will last a whole 24hr+ drawing session).
Full size version can be seen on Flickr, should you so desire, where I am known as AgentX-2-0. https://flic.kr/s/aHsjC5y7Xp.
Comments welcome!![Image]()
![Image]()
↧
Re: Death 2 Sharpie 1st go
Hi Jinja,
Lovely drawings, been playing with Death To Sharpie and my Polograph for a couple of weeks now and I must say I'm impressed with your results. You seem to be having much better luck getting the shades to come out in the drawings than me, Mine tend to end up more black and white. Think it might have something to do with me not scaling the image properly in DTS. I'll enjoy playing with it more and finding out.
I've attached some pictures of my results, please ignore the couple of stray lines in the Easyrider one, had some mechanical issues which I hope to have fixed.
![Image]()
![Image]()
Hope to see more of your drawings.
Regards
Hope to see more of your drawings.
Regards
↧
Re: Death 2 Sharpie 1st go
@Jinja - Very nice! I've found it very hard to get the settings right with Death To Sharpie, but it seems you've found the recipe. Any tips you could pass along?
BTW (everybody), adding your drawings to the Drawbots Flickr group would class up the joint:
https://www.flickr.com/groups/2164129@N25/
↧
↧
Re: Death 2 Sharpie 1st go
Thanks for the comments both, glad you like them. @reconlap, the Easy Rider one in particular looks pretty nice, look forward to seeing how you develop that.
@kongorilla, as you might imagine there were several poor attempts before I started to get things I liked :) The first thing I did was to ditch sharpies - the Tombow pens give consistent results over the life of the pen, particularly in line width and ink flow. I also don't use a black pen - the code that comes out overdraws the dark areas a lot so it will end up saturated so I use a dark grey or medium grey.
On the image prep front, I have a large library of B&W negs from when I had a darkroom so I have been using those, though I do have some from colour images in the works that seem to be coming out ok. Anyway, I desaturate (if colour) then adjust the image to reduce contrast and get the broadest possible range of greys. For both pictures I removed clouds in the sky completely as they just distracted from the image. also, for the Kings cross one I had to manually add a darker line for the very top edge of the building as it just wasn't coming out in D2S.
Then I do literally dozens of D2S renderings, tweaking the parameters constantly.
I adjusted the on screen output to get it as large as possible so I can see the results better, but I found that fiddling with the paper size settings has a dramatic effect (usually detrimental) so I pretty much leave 'em alone.
For the main fiddlable parameters I had these for example for the Church image:
final int squiggle_total = 650;
final int squiggle_length = 700;
final int half_radius = 3;
final int adjustbrightness = 5;
final float sharpie_dry_out = 0.0;
final String pic_path = "Church1a.jpg";
I added a couple of my drawings to the Polargraph Flickr group as you suggested.
I'll post a bit more later when I have more time. Off to work!
↧
Re: Death 2 Sharpie 1st go
To continue..
I start by playing with the brightness to get an overall nice look, adjusting up or down by 2's or 4s and finally in single steps until I thinks it's ok. Then I play around with the squiggle_length and the squiggle_total to try and bring out details that aren't showing up nicely, usually up/down by 200's at first then smaller increments until I think its as good as I'm going to get. I try and be disciplined and only fiddle with a single parameter between each run of the sketch. Sometimes I go back to the original image and tweak the curves or the brightness/contrast a bit, or adjust the resolution. Generally I find 1000-1200 pixels by 700-800px is a good starting point but it varies from picture to picture. Oh, and I added a border too.
Just for reference (and in case anyone wants to have a go with them) here's the original photos I used:![Image]()
![Image]()
↧
Re: Death 2 Sharpie 1st go
Thanks for the detailed write-up, JingaBeardy. I put Death to Sharpie experiments on hold until I finish building plotters that use Koh-I-Noor Rapidograph pens, so I can draw with custom inks; I came to same conclusion you did regarding using black inks. Ballpoint looks good, though. Still, I found it hard to get the plot out of the dark values fast enough without over drawing every mid-value area as well. Very touchy parameters.
It'd be nice to get the output as SVG, so errant squiggles could be deleted. Like, why did it draw those squiggles on the sky borders of your Kings Cross drawing? All my drawings have something like that as well.
Maybe we could coax an appearance by Scott Cooper in this forum. Some recommendations from him would probably save us much time and art supplies.
↧
Zebratrace on OS X
I just managed to get ZebraTrace to work on my mac using Homebrew.![Image]()
brew install pyqtAfter everything has been installed you need to update your path as brew will tell you. My commands looked like this:
Python modules have been installed and Homebrew's site-packages is not in your Python sys.path, so you will not be able to import the modules
this formula installed. If you plan to develop with these modules,
please run:
mkdir -p /Users/MyName/Library/Python/2.7/lib/python/site-packages
echo 'import site; site.addsitedir("/usr/local/lib/python2.7/site-packages")' >> /Users/MyName/Library/Python/2.7/lib/python/site-packages/homebrew.pth
Then you can start it with:python ZebraTrace.pywHope that helps someone...
↧
↧
New polargraph with lightbox
Hey people!
Today i finally got my polargraph running.
I used some monofilament fishing line and it works ok i think, in hte future i will probably move to GT2 belts instead.
The touchscreen issue affects my machine also and since i haven't been able to fix it by grounding (believe me i tried) im now running it from my computer wich is terribly slow.
Sandy was a good sport about this and offered my hard earned money back, instead i found the touchscreen on ebay and ordered one there too since shipping would cost me the same as having a new touchscreen at my doorstep.
I built it on a lightbox made of a Ikea floor protector, some wood i had laying around and some RGB led strips.
Im still in limbo to keep it landscap or go potrait.
Now to learn how to draw !
![Image]()
![Image]()
↧
disappointment
After calibrating the screen Arduino library does not respond to touch with any version of the software polarshield except with the compiled version 1.10.
Therefore you can not modify parameters in the code or use a newer version of firmware . can not enjoy the bugs fixed since version 1.10.2 (the error screen is not static as reported on the blog, is clearly an error of logic)
Regarding the control software, versions not only compiled from processing work. The executables in both 32- and 64 generate an uncontrolled java error and can not make a proper debug .
The experience with this product since its acquisition to its implementation is terrible.
↧
Re: disappointment
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
↧
Re: Zebratrace on OS X
To bundle everything up and use it like a regular app I found Platypus. It creates a wrapper and builds an .app so that you just double click on it. No need to run it from the terminal.
↧
↧
Draw Speed
I just noticed that the bot draws a lot faster when I switch to the setup or queue screen instead of the input screen. Probably has do do with the 80000 lines that are being drawn all the time.
Which makes me wonder if there is a way to just send the gcode to the bot without a processing sketch sucking up tons of computing power?
↧
Re: disappointment
Excuse for my english
- Touchscreen only run with the hex version 1.10 compiled (Xloader).
- Compiled controllers in two flavours (32 and 64 bits) It generates an unhandled exception and not run. Tested on multiple computers with different versions of JRE.
I think you should create and publish a line of stable versions of software versions polarshield and libraries that work.
↧
Re: disappointment
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
↧
Re: disappointment
Quizas el idioma en este caso es una barrera. Debe comprender que todos tenemos el mismo interés por la tecnología de microcontroladores y respeto y apoyo su labor. Antes de embarcarme en este proyecto, ya he construído y puesto a funcionar dos impresoras prusa i3 y un cnc.
Mis indicaciones son en función de una mejora en la forma de suministrar el software al igual que hace Reprap o Makerbot o en su defecto indicar el producto "as is".
No es una crítica destructiva, todo lo contrario. Sepa con seguridad que estoy trabajando en el problema del lcd y si avanzo en resolver algo con otras versiones de software, lo voy a publicar en su foro.
Respecto a la adquisición del producto ya le he enviado un correo privado.
Saludos.
Perhaps in this case the language is a barrier. You must understand that we all have the same interest in technology microcontroller and respect and support their work.
Before embarking on this project, I've built and put into operation two Prusa i3 printers and cnc.
My indications are based on an improvement in the way of providing the software as it does Reprap or Makerbot or otherwise indicate the product "as is".
No It is a destructive criticism, quite the contrary. Know for sure that I'm working on the problem of the lcd and if advance in solving something with other versions of software, will post on their forum.
Regarding the acquisition of the product and I have sent a private email.
Regards.
↧
↧
Re: Death 2 Sharpie 1st go
@kongorilla Processing doesn't export SVGs natively but it has PDF export.
I changed a few lines and uploaded the resulting sketch to my Blog.Death to sharpie with PDF export
↧
Re: Death 2 Sharpie 1st go
@Krummrey - COOL! Thanks! I'll try it soon. :)
edit: Just exported the default image...WOW! It's cool to get a good look at the exported lines in Inkscape. They have a more angular character than I had previously appreciated.
↧
Re: disappointment
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.
↧