March 27, 2017, 07:44:22 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: You may have to login twice the first time,  but we don't know why - Erm I mean it's a security thing yeah that's it - security.
   Home   Help Search Login Register  
Pages: 1 [2] 3 4 ... 10
 on: March 14, 2017, 07:05:37 AM 
Started by Tymnus - Last post by zacpla
Thank you for your prompt answer Ertew, I will try it and I will give a feedback on this ASAP

 on: March 13, 2017, 10:35:26 PM 
Started by Tymnus - Last post by Ertew
1. Pro micro and clones are incompatible with Teensya 2.0 There are two problems: pinout (different pin names, not big deal) and bootloader (arduino bootloader suck). Rest (uC, crystal, USB section) are almost identical.
I tried to program old WaxBee into pro micro. With success. But I need external programmer to do that. More info here: http://forum.bongofish.co.uk/index.php?topic=2556.0
Newer WaxBee version have smaller size thus You can use arduino bootloader that are inside pro micro. Just programming process are different. WaxBee can program teensy or generate hex file. You need manually call AvrDude with specific parameters. That's probably the most important difference.

2. You need working EMR pen. Original Wacom pen will be excellent as long as it working (moisture and time may destroy everything). Replacement pen may working too but I never played with that.

 on: March 13, 2017, 09:52:36 PM 
Started by Forestfrog - Last post by Ertew
Well. Diffuser have direction because LEDs are only at one side. If You 'fix' the problem by removing silver tape and glue it on the other side, the diffuser will still spread more light on right side and less on left.

Yes, when You move LED strip, You need to rotate diffuser layer.
What about upper layers? IMO You need to rotate only diffuser section which may contain only 'glass' or 'glass' and single sheet above. You can easy test all layers. If layer have different structure/density at different regions it's part of diffuser. If layer have the same structure at any point, it may be lens or something similar. You not need to rotate that.
And please pay attention to layers order and top side. If You mess with that, You will never found the right order.

BTW, why You need to rotate backlight and all optical layers? IMO You can rotate LCD glass without moving frame and backlight, then rotate whole module.

 on: March 13, 2017, 09:49:33 AM 
Started by Tymnus - Last post by zacpla
Hello Everybody,

A little bit lost in my deep french countryside, I am trying to convert my old serial UD 1212 r Wacom into an usb one.
Many thanks to Bernard, Red five, DOCa Cola and all the contributors for their explanations, who are very usefull.
I just want to ask two questions:
1. Is it possible to make that transformation using an Arduino pro-micro Teensy 2.0 compatible device as this one:
2. May I use my old wacom pen or is it absolutely necessary to buy an Axiotron Studio Pen?

Best regards,


 on: March 13, 2017, 09:10:11 AM 
Started by Forestfrog - Last post by Forestfrog
Hello Ertew,

thanks for your answer - just a short reply from me before heading off to work:

I found part of the problem (or rather noticed what was right before my eyes....) the diffuser does have an orientation. Which in this case means, that at the small sides of the "glass"-block that is the diffuser, only one is open(right side), the other three are covered by thin strips of a white material.
Now as I rotated the LED-strip to get the wires coming out on the upper side, I also put it on the other side(left) of the panel to have it shining towards the diffuser again. But as I did not rotate the diffuser as well, it was always shining through one of those thin white covers, which likely swallowed a lot of light. Yay perceptive me  Tongue

So next step will be trying to rotate the stack below the LCD-layer by 180% to check if this solves the problem without creating any other. (I would like to try to switch the wires powering the LEDs for a flat cable, but I can't find a matching connector. Starting with not knowing how it is properly called so I can search for it.)

The correct alignment of LED strip and diffuser is still another point, of course.

 on: March 12, 2017, 05:30:34 PM 
Started by Forestfrog - Last post by Ertew
Edit: The thing that is bugging me the most right now is the placement of the LED strip. At the moment I only manage a "visible, but quite dark" setup, especially at the right side (LED is on the left) of the screen it is very dark. I guess that has to do with finding the best height so the LEDs shine directly into the diffuser layer.
Does anyone know, if "closing" the other three sides (with black tape etc) so no light can escape would improve things?

If I understand You right, You have a problem with backlight diffuser. LEDs are on left and left side are far more brighter than the right side.
Yes, there are may be problem with alignment - LEDs emit light above diffuser, maybe directly at one of focusing layers. Proper diffuser should reflect small amount of light (from high light beam) at left side, more (from moderate light beam) at the middle and all remaining light (smallest light beam) at the right side.

The escaping light shuldn't be a problem. IMHO light leakage at remaining 3 sides will be less than 10%. Reflecting them back shouldn't improve the overall effect.
If light leakage disturb You (by illuminating buttons or desk), black tape are OK for catch the light. In Your case You may check something reflective to reflect light back into panel - silver tape or at least white tape.

 on: March 12, 2017, 02:09:39 PM 
Started by Forestfrog - Last post by Forestfrog
Regarding the classic pen - I like it. It is like a slim ballpoint pen, very leightweight, comfortable for my hand. Also, in what little testing I did, the pressure curve was alright. With the Ugee tablet I had to install lazy nezumi to adjust the pressure curve in PS (CS2, so afaik no suitable in-program-tool) so I did not have to press down so hard.
Somewhere I do have an Intuos2 A5, if I can find it (and install it side by side with the Intuos4) I can do a little more detailed comparison between both pens.

Attached a crappy picture of all three pens, top to bottom: Intuos 2 pen, Intuos4 classic pen, Ugee pen.
[ Attachment: You are not allowed to view attachments ]

As for progress - I made a temporary heatsink for the LED-strip, just some bent aluminum plate. It works well as it is getting quite hot, so removing heat from the LEDs, but the thermal pad I used to stick both together wasn't sticky enough, so they came apart after a few minutes.

Still, during this time I was able to play with the monitor frequency a bit, moving it above 60Hz reduced jitter notably - now there is only a light wiggling at the left and right side of the screen.
The sweet spot starts at 62Hz, up to 64Hz I see no change and I didn't try higher frequencies(also no smaller increments, as the driver only allows full steps.) 59Hz made it worse, so I didn't go any further in that direction.

Also, I removed the copper tape covering the screen-circuitry at some point to check how much shielding this might play into it - absolutely no change, so jitter and shielding(that part) seem to have no connection right now.

There still is that issue that I have to open the driver window by mouse-click to get the pen recognized, before that the pen is being ignored.

Edit: The thing that is bugging me the most right now is the placement of the LED strip. At the moment I only manage a "visible, but quite dark" setup, especially at the right side (LED is on the left) of the screen it is very dark. I guess that has to do with finding the best height so the LEDs shine directly into the diffuser layer.
Does anyone know, if "closing" the other three sides (with black tape etc) so no light can escape would improve things?

 on: March 09, 2017, 11:22:51 PM 
Started by DaBotz - Last post by DaBotz
This is a small Java application that allows to place  a number of "reference" pictures on the desktop,
and above your preferred drawing software, too...

Be gentle, I wrote it in a spur of Java fever, and it shows it, a bit.

My idea was to be able to have some photo references at hand, without having to print them, and without
feeling too much the temptation to just import them inside the drawing software and trace over them (which follows Wally Wood mantra, maybe a bit too much to the letter).

This is, really, the main "Original Sin" of having moved completely to the digital side (the SimtiQs are just too good).  

The application can open a series of small windows, that can be resized, moved, each one showing an image that can be resized and clipped (of course, just what we see - it is non-destructive).

It memorizes the parameters of each one, so that each frame will be restored more or less exactly the next time the application will be launched, and or when their  set ("Session") will be reloaded.

It can grab the images from the system clipboard (useful on google and the likes) automatically, or with a usual ctrl v (kind of... it depends a bit from what element in the GUI have focus, so it can misfire).

It has a management frame, a configuration window, a system tray icon with a pop-up menu... and its  share of small bugs (I will sort them out, with time).  

It is possible to decide to keep more than one set of reference pictures (which, by the way, need not be in any specific location on the computer, though the application stores its auto-saved clips in one location), each one called a "Session"...

Theoretically, one could have "cars", "flowers", "reference for Xyz drawing" etc.

Note that it has been designed for use, originally, as a back end to Windows' "Send to" feature...

To work with it, when my little app is run, it first tries to call any "older" copies of itself through TCP on the local machine, and if one instance of it is already open and listening (i.e. has already loaded all the GUI), the process spawned by the "Send To" event will simply send its "sister" the list of files to add, and die.

With no graphics involved, it is relatively fast.

For this reason, when the App runs for the first time, firewalls may pop a warning and ask to deny/allow the connection.

 A suggested trick, to keep things under control: instead of launching it using the standard javaw.exe virtual machine, I make a copy of javaw with a specific name,  and use a short-cut to launch the Jar - it makes easier check what this - and all the others small java apps that I wrote, each is created through a JW[nameApp].exe copy of javaw - really do in my computer. Opening the task manager, each different copy is identifiable by its name , which makes easy kills what misbehave, or runn┬íng an analysis on it using Process hacker.

If you do not allow it to use TCP, every call will open a new instance of the application (once upon a time, I used a .lock file system, but it was prone to jamming).

If you authorize it in the firewall, only one instance may run at each time (which is plenty enough, really).      

The 32 bit jar is compiled against Java 1.7.

The 64 bits version is compiled against Java 1.8.


Direct interface with a mouse or a pen on the image frame:

The left slider is the zoom.

The right and bottom sliders behave like scrollbars (and should disappear when not in use).

To move the picture inside its frame, pick it with the mouse below the file name area

To drag the whole picture frame, either pick it on the  top (where is the name of the file),  or click the right button of the mouse while moving.

Theoretically, clicking the central button should set it in "zoom" MODE, but I have no mouses at the moment, and my Wacom driver is a bit of a prick, so I haven't tested it.

All these actions are mirrored on the "Remote Mouse" area of the admin window - on it, it also work using shift (drag the highlited image frame) and ctrl (UP-down: image zoom; left-right: changes the size of the frame.)

Also, the image frames can be moved by selecting one in the admin frame (keys A and Z to chose the selected frame) and using the keyboard arrows (shift makes the movement faster, ctrl makes the frames jump monitor)

Odd functions: in multi-monitor systems, each picture shows also a "Jump to next screen" button in the right upper corner, just aside its _ (hide) button.
Also, for multi-monitors set-ups, there is the option (in the settings) "Crossing screen boundaries is unsafe".

I added these because, I discovered, when you have a multi-monitor set-up with more than one graphic board, when you cross between monitors controlled by different boards,
Java applications can and usually freeze (this happens also with the DisplayLink usb... as far as I can understand, it is some bug, but where? in my work, in the Java Swing framework, in my computers...)

If  "Crossing screen boundaries is unsafe" is set, the Jump Screen buttons ( on the frames, or in the management table) become the only mode to move the frames ( and the admin window)
from one monitor to the other (or the "Remote Mouse", which makes them "Jump" to the screen the mouse has entered).

Adding images to the sets can be done in four ways of increasing simplicity:

 Using an "Add Image" button ( or the Add Image function of the Tray ) - it is the most unhelpful way.

 Passing a set of paths to files (i.e. using a Windows "Send to" feature, or similar)

 Copy-pasting the image.

 Telling it to continuously "Grab The clipboard" (again, on the Admin frame or in the Tray pop-up menu) - every time one copies an image, it will automatically build it in a frame.

(Both copy-pastes may not work, depending on how the app you do the copy in classifies the image data; It works wondrously with my Firefox and Manga Studio, it fails with windows image viewer. )

Note: over time, I shall add keyboards short-cuts for every action... configurables? Aaagh

The Jar can be found here:


that is part of my contribution to Simtiqitude that can be found in:


For those of us that miss the possibility to have a hierarchy of options under the "Send to" feature in windows, I added my implementation of a structured system for it.

It is still in Java (1,7 ? I think), and it does call itself through TCP (it's faster than using files, and I do not have to keep writing over the same spots in my SSD) so that, after the first time, it is very fast (note to self: do not cross-monitors with this).  

Finally, to make people envy my genius,


[ Attachment: You are not allowed to view attachments ]

Because of not only of plywood is Dabotz the master...

 on: March 09, 2017, 09:47:28 PM 
Started by Forestfrog - Last post by DaBotz
Let me know something about the Classic Pen .

I have a Intuos 4 Grip pen  - my first build, that I still use at night, was a "TabletMod L" derivative, witn an Intuos 4  large and a 15.4" AUO panel - and I hate it.

Not only the form of it, but also the fact that I feel the tip of it fitting a bit more loosely than in the Intuos 2 Pens (which already are not a Rotring RapidoGraph), and its pressure sensor not only is not very linear, it tends to "weaken up" after half an hour or so.

That, and the prices, are the factors that decided me to stick with the Intuos 2 (that I bought just to make a try for something with better colours, to use at night - it's... complicated) till I can.

I may opt for an Intuos 3 (the inch of screen or so that the Intuos 2 12x18 does not cover are a bit of a bother)... some day.

I've seen that newer Wacoms have 8092 pressure levels.

I hope that they got them more linear, because if they are like my I4 Grip Pen, I see no real improvement in more precision (which is not the same as accuracy, by the way - see the 5080 lpi - 0.005 mm precision - vs the 0.5 mm accuracy of the tablets beyond the Intuos 2... by the way, for a DiY-tiq spatial accuracy is as important as the precision, or more).  

How does feel, the I4 classic pen?

 on: March 08, 2017, 01:32:00 AM 
Started by roipoussiere - Last post by bernard
Waxbee is the reverse of what you need. 

The easiest and more promising I think would be to get a linux-based system, run the standard wacom drivers and interface that with, say "Python" to do whatever pleases you. (no need to buy a costly Rasberry PI, there are other alternatives like the 9$ "C.H.I.P.")


Before buying check if you can find a solution to talk to your "motors" or other hardware devices.  These boards typically come with lots of GPIOs.

Pages: 1 [2] 3 4 ... 10

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!