Closed pjsilvahot25 closed 3 years ago
Are you familiar with building software on linux? If so, you'll need CMake, libsvg, libxml2, gnu make, g++, and libsdl. Run cmake ., then make, then cd util, then ./draw_svg
Otherwise, this software really isn't ready yet for people without a little bit of hacking skill.
I'm attempting to build libcutter on Ubuntu. I can't find any package that gives me the svg.h header file that draw_svg.cpp depends on, so I tried compiling libsvg from source from here (http://www.t2-project.org/packages/libsvg.html).
Running ./configure crashed because it couldn't find 'libxml-2.0' (I had already installed ubuntu's libxml2 package). I installed libxsm++2.6-dev and the configuration script finished successfully.
Unfortuantely compilation now fails with the following error: svg_image.c:25: fatal error: jpeglib.h: No such file or directory compilation terminated.
Any suggestions?
You'll need a libjpeg-dev. I think ubuntu might have it listed as libjpeg62-dev?
As for libxml-2.0, I had to install libxml2-dev for debian based systems to build libsvg.
Also, libsvg-0.1.4.tar.gz from http://cairographics.org/snapshots/ is what I used for libsvg.
Thanks, that did it; everything now seems to compile correctly (both libsvg and libcutter) but I've got a few more questions:
First: when I try to run cutter-logo.py python still can't find the "cutter" module; I imagine I just don't have it in my path. How should I run the logo interpreter so that it works?
Second: draw_svg can't find the libsvg shared object file for some reason: "./draw_svg: error while loading shared libraries: libsvg.so.1: cannot open shared object file: No such file or directory"
Third: draw_gcode doesn't seem to work. I'm not sure if it's because I'm pointing it at the wrong device or because my keys are wrong (I have firmware v1.31; I see references in the libcutter wiki to v1.34...could that be it?), but when I run draw_gcode using the pololu test code it prints out the first command and then seems to hang. Of note, the text on my cricut's LCD freezes, so I'm guessing I've got the right serial port but I'm not passing it good information. If it's the firmware version, should I update or change the keys? In either case, how should I go about doing that?
Thanks again.
Update: The Windows version of the cutter-logo.py script on the built-to-spec blog (http://www.built-to-spec.com/blog/2010/08/16/cricut-direct-pc-control-working/) worked correctly for me, so I don't think I need different keys.
It's entirely possible, however, that I didn't put the keys into my keys.h file correctly. As a first step could you point me at a properly formatted keys.h file?
For the missing library for draw svg, you can set "export LD_LIBRARY_PATH=/usr/local/lib", or whereever libsvg is installed On Apr 25, 2011 11:29 AM, "kylemarsh" < reply@reply.github.com> wrote:
Update: The Windows version of the cutter-logo.py script on the built-to-spec blog ( http://www.built-to-spec.com/blog/2010/08/16/cricut-direct-pc-control-working/) worked correctly for me, so I don't think I need different keys.
It's entirely possible, however, that I didn't put the keys into my keys.h file correctly. As a first step could you point me at a properly formatted keys.h file?
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1053557
Ahh...and that's an environment variable, not something to set during compilation, right? Thanks.
Yes, but you can add it to /etc/ldconfig.conf if you like. On Apr 25, 2011 5:47 PM, "kylemarsh" < reply@reply.github.com> wrote:
Ahh...and that's an environment variable, not something to set during compilation, right? Thanks.
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1055611
The lcd freezing and unit possibly rebooting looks like bad keys. On Apr 25, 2011 5:19 PM, "Richard Allen" rsaxvc@mst.edu wrote:
For the missing library for draw svg, you can set "export LD_LIBRARY_PATH=/usr/local/lib", or whereever libsvg is installed On Apr 25, 2011 11:29 AM, "kylemarsh" < reply@reply.github.com> wrote:
Update: The Windows version of the cutter-logo.py script on the built-to-spec blog (
http://www.built-to-spec.com/blog/2010/08/16/cricut-direct-pc-control-working/ ) worked correctly for me, so I don't think I need different keys.
It's entirely possible, however, that I didn't put the keys into my keys.h file correctly. As a first step could you point me at a properly formatted keys.h file?
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1053557
Yes, that's my thought as well. Setting that environment variable has made draw_svg work correctly, so now I just need to nail down the keys.
My keys.h file looks something like this:
#ifndef KEYS_H
#warning Keys must be defined!
#define MOVE_KEY_0 0x47302A23ul
...
#define LINE_KEY_0 0x272D6C37ul
...
#define CURVE_KEY_0 0x7D316E22ul
#endif
In the mean time I'll play around with these and see if I can get it working. Thanks for all your help.
The 0x prefix is important. The ul postfix might be important - if in doubt, use it here
To set up a new keys.h, copy the keys.h from pub/keys.h to a directory above. Remove the #warning, and copy the new keys into the file.
Your line and curve keys differ from mine. (you got 1,2,and 3 to go along with 0, right?) We learned there are a few different commands for line that are very similar - I think they are: Start with pen up and draw a line, picking up pen at end Start with pen down and draw a line, keeping pen down at end Start with pen down and draw a line, picking up pen at end
The same goes for curves. Right now libcutter will only use one at a time, so I use start with pen down, draw a line, and keep pen down for everything, and since move commands always pick up the pen it works out.
On Mon, Apr 25, 2011 at 8:30 PM, kylemarsh < reply@reply.github.com>wrote:
Yes, that's my thought as well. Setting that environment variable has made draw_svg work correctly, so now I just need to nail down the keys.
My keys.h file looks something like this:
ifndef KEYS_H
warning Keys must be defined!
define MOVE_KEY_0 0x47302A23ul
...
define LINE_KEY_0 0x272D6C37ul
...
define CURVE_KEY_0 0x7D316E22ul
endif
- Do I need to include the rest of the keys?
- b. if so, what should the macros be named?
- Did I get the right keys matched with the right names?
- Do I need the trailing "ul" or the "0x" prefix?
In the mean time I'll play around with these and see if I can get it working. Thanks for all your help.
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1056149
Hmm. I moved keys.h up into the libcutter/include directory as you said and removed the warning from that copy of the file, so upon recompiling it appears to be using the updated file. I also switched out my LINE_KEYs and CURVE_KEYs; I believe you said that I was using the same MOVE_KEY as you were (and yes, I am using all 4 keys for each command)
The new keys are #3 for LINE (first word is 0x303F6863) and #5 for CURVE (first word is 0x343A2148); these are listed as "Lower stylus and cut [line|curve]" on the wiki. I've tried both with and without the ul postfix to no avail. My problem may, in fact, be elsewhere, but to confirm that before I tear off in the wrong direction, could I impose upon you to throw your keys.h up somewhere that I can get to it? On the wiki maybe? Thanks again.
By the way, I'm documenting my progress through getting set up on the wiki, so hopefully future users will be able to follow without too much trouble: http://www.built-to-spec.com/cricutwiki/index.php?title=Setting_Up_Libcutter
Have you tried any of the test programs like test_speed.cpp?
I have. I'm getting the same behavior from them:
% ./test_speed /dev/ttyS1 Divisor=0 r=0 <hangs; cricut LCD readout freezes>
Not sure what to do from here; it seems to me as though I am managing to send data to the cricut but it's not recognising the data and so it never replies. As you've mentioned before, a likely cause would be bad keys and I don't know exactly what the keys.h file should look like. A sample would go a long way towards eliminating that as a possible cause of my troubles.
Any further help you can give will be appreciated.
Have you tried /dev/ttyUSB0? On May 1, 2011 9:28 PM, "kylemarsh" < reply@reply.github.com> wrote:
I have. I'm getting the same behavior from them:
% ./test_speed /dev/ttyS1 Divisor=0 r=0 <hangs; cricut LCD readout freezes>
Not sure what to do from here; it seems to me as though I am managing to send data to the cricut but it's not recognising the data and so it never replies. As you've mentioned before, a likely cause would be bad keys and I don't know exactly what the keys.h file should look like. A sample would go a long way towards eliminating that as a possible cause of my troubles.
Any further help you can give will be appreciated.
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1086366
I don't actually have /dev/ttyUSB0, I don't think. My ubuntu install is on a VMware virtual machine that's forwarding a serial device to my Windows 7's COM4, which is where the Cricut shows up. This could be part of the problem, but I'd like to eliminate other variables.
Ooh. The cricut doesn't use a normal serial baud rate. Can you instead set up the vm to pass the usb directly to the ubuntu?
I'm currently away from my keyfiles. On May 1, 2011 9:49 PM, "kylemarsh" < reply@reply.github.com> wrote:
I don't actually have /dev/ttyUSB0, I don't think. My ubuntu install is on a VMware virtual machine that's forwarding a serial device to my Windows 7's COM4, which is where the Cricut shows up. This could be part of the problem, but I'd like to eliminate other variables.
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1086397
That makes sense. I'll see what I can do; I'm not sure that Windows ever exposes it as a USB, though. I don't know much about how Windows handles USB devices, but when I plug in the cricut it notices that it's an FTDI device and loads up those drivers to hook it up as a COM port. If nothing else I can try booting into ubuntu directly on some machine and doing things directly. I'll let you know what happens.
Hmm...I was able to get VMware to forward the USB device and that made it start working! I discovered that keys 3 and 5 make the blade pick up after each cut and keys 4 and 6 don't, so 4 and 6 are the correct ones. I've been doing "dry cuts" so far without blade or mat in to preserve my blade and mat, but I think it may be time to start experimenting with actual paper in the machine.
Thanks for all your help, guys!
We should probably try and detect a failure to set the baud rate properly and signal a warning somehow. On May 2, 2011 12:03 AM, "kylemarsh" < reply@reply.github.com> wrote:
Hmm...I was able to get VMware to forward the USB device and that made it start working! I discovered that keys 3 and 5 make the blade pick up after each cut and keys 4 and 6 don't, so 4 and 6 are the correct ones. I've been doing "dry cuts" so far without blade or mat in to preserve my blade and mat, but I think it may be time to start experimenting with actual paper in the machine.
Thanks for all your help, guys!
Reply to this email directly or view it on GitHub: https://github.com/vangdfang/libcutter/issues/3#comment_1086621
Has anyone made this work with the win32 compile and MinGW on Ubuntu? I've made a few changes to get this far, but now I'm seeing the following error. I think this means that the linker can't find the svg lib, but I'm not familiar with the error. Any pointers?
[ 54%] Building CXX object util/CMakeFiles/draw_svg.dir/draw_svg.cpp.obj Linking CXX executable draw_svg.exe /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -lsvg collect2: ld returned 1 exit status make[2]: * [util/draw_svg.exe] Error 1 make[1]: * [util/CMakeFiles/draw_svg.dir/all] Error 2 make: *\ [all] Error 2
I don't think anyone has built it with MinGW, but it does appear to be missing the libsvg library.
I was able to get past those errors by adding the /usr/local/include and /usr/local/lib to the CMakeList.txt. I'm now getting an error stating that it can't find the methods svg_create, svg_destroy,etc from the draw_svg.cpp around line 834. I have a feeling that this is because libsvg was compiled with the Ubuntu g++ instead of the mingw g++. I'm going to try reinstalling the libs with the mingw compiler next. Jfyi, it does talk about using mingw in the win32 build files. Also, thanks for your instructions on the Ubuntu version. They were very easy to follow.
It looks like it's going to be a bit difficult to get libsvg compiled using the mingw32 compiler. Before I go that rought, any other ideas for this error? Some of the files like draw_gcode compile successfully, so I assume this is a libsvg issue. Here's the full error.
Linking CXX executable draw_svg.exe
CMakeFiles/draw_svg.dir/objects.a(draw_svg.cpp.obj): In function main': /home/phiz/source/win/libcutter/util/draw_svg.cpp:806: undefined reference to
_svg_create'
/home/phiz/source/win/libcutter/util/draw_svg.cpp:807: undefined reference to _svg_parse' /home/phiz/source/win/libcutter/util/draw_svg.cpp:809: undefined reference to
_svg_get_size'
/home/phiz/source/win/libcutter/util/draw_svg.cpp:812: undefined reference to _svg_render' /home/phiz/source/win/libcutter/util/draw_svg.cpp:814: undefined reference to
_svg_destroy'
collect2: ld returned 1 exit status
make[2]: * [util/draw_svg.exe] Error 1
make[1]: * [util/CMakeFiles/draw_svg.dir/all] Error 2
make: *\ [all] Error 2
So, it all compiled, it just didn't link. What do you see running objdump -T [path to libsvg.so]
Thanks, that helped. It looks like the names were mangled. I assume this is because I am trying to cross compile. I think that I'm giving up on the win32 version for now unless anyone has further pointers. I'm going to work on the Unix version for now.
closing - stale
How do you import an svg file and cut from it?