Inkcut Glitchy & Slow after Cutting Cycle Breaches est. 1.5 Minutes

Nedly
Oct. 21, 2020
chat_bubble_outline 12
  • link
    Members 10 posts
    Oct. 21, 2020, 3:16 p.m.
    link

    Hello, and thank you to everyone who has contributed to or supports this community. I am newish to cutting and have enjoyed my time with Inkscape and Inkcut.

    I am having an issue though. Inkcut performs perfect cuts with my cutter until after 1.5 minutes or so. I have tried a range of things - I doubled graphics within a single SVG file. I have also tried using the duplicates tool within Inkcut. It cuts great at first, then randomly slows down, sounds almost glitchy and takes forever to finish the cut.

    Lately I have been cutting smaller chunks, then exiting the app, relaunching it and continuing and this method works well for smaller graphics.

    I read somewhere about a potential Python error for a ??MaxResource?? flag, or some limitation that was taking place against the user. I also had someone recommend that the memory of one cut was not getting dumped before the next, though I was not sure if this would be the case if there is a single SVG file containing multiple cuts because it would be seen as one file.

    System & Setup:
    Debian Linux, Python 3 / Python3.6 Pip3
    Inkcut 2.* w/ Inkscape
    Thinkpad; 8gb's RAM, 720gb HD, quad core processor w/ integrated graphics
    Red Sail Vinyl Express R Series II
    Vinyl Cutter using settings recommended from manual (baud rate 9800, 1 step, H protocol, XON/XOFF, etc)

    Other things I have tried: I tried a few different drivers, protocols, etc - the error seems to be consistant no matter what settings I put into place (within Inkcut) and no matter which driver I choose. I also tried running the inkcut command in Linux as nice -n 18, for a higher priority, however I did not see any change - again, after about a minute or minute and a half, it will slow down substantially and sounds nearly glitchy.

    It does seem to me like a resource is becoming full, or a limitation somewhere is being set, probably in the Linux system or with the user. I added the user to dialout group and adjusted the permissions for the ttyUSB0 port. I have great connectivity to the plotter - I can use Inkcut's virtual controls to adjust the blade, position, etc. Cuts also complete without error - even when the glitch takes place.

    Any suggestions??? Anyone had this error before? I have been able to work around the error with smaller cuts, and I perform a cut - restart the app, and then I can reposition my blade and perform the next cut, reset the app and repeat. Though this has been daunting, and if I had any larger of graphics to cut it would be huge wait times. I find it interesting that relaunching the app stops the error momentarily. It certainly seems like a resource is getting filled up so to say..

  • link
    Members 10 posts
    Oct. 21, 2020, 3:24 p.m.
    link

    ** My apologies, this is a cross post as I posted in the General category; I wanted to move it here to Software Help and could not find a way to move or delete my other thread.

    Hello, and thank you to everyone who has contributed to or supports this community. I am newish to cutting and have enjoyed my time with Inkscape and Inkcut.

    I am having an issue though. Inkcut performs perfect cuts with my cutter until after 1.5 minutes or so. I have tried a range of things - I doubled graphics within a single SVG file. I have also tried using the duplicates tool within Inkcut. It cuts great at first, then randomly slows down, sounds almost glitchy and takes forever to finish the cut.

    Lately I have been cutting smaller chunks, then exiting the app, relaunching it and continuing and this method works well for smaller graphics.

    I read somewhere about a potential Python error for a ??MaxResource?? flag, or some limitation that was taking place against the user. I also had someone recommend that the memory of one cut was not getting dumped before the next, though I was not sure if this would be the case if there is a single SVG file containing multiple cuts because it would be seen as one file.

    System & Setup:
    Debian Linux, Python 3 / Python3.6 Pip3
    Inkcut 2.* w/ Inkscape
    Thinkpad; 8gb's RAM, 720gb HD, quad core processor w/ integrated graphics
    Red Sail Vinyl Express R Series II
    Vinyl Cutter using settings recommended from manual (baud rate 9800, 1 step, H protocol, XON/XOFF, etc)

    Other things I have tried: I tried a few different drivers, protocols, etc - the error seems to be consistant no matter what settings I put into place (within Inkcut) and no matter which driver I choose. I also tried running the inkcut command in Linux as nice -n 18, for a higher priority, however I did not see any change - again, after about a minute or minute and a half, it will slow down substantially and sounds nearly glitchy.

    It does seem to me like a resource is becoming full, or a limitation somewhere is being set, probably in the Linux system or with the user. I added the user to dialout group and adjusted the permissions for the ttyUSB0 port. I have great connectivity to the plotter - I can use Inkcut's virtual controls to adjust the blade, position, etc. Cuts also complete without error - even when the glitch takes place.

    Any suggestions??? Anyone had this error before? I have been able to work around the error with smaller cuts, and I perform a cut - restart the app, and then I can reposition my blade and perform the next cut, reset the app and repeat. Though this has been daunting, and if I had any larger of graphics to cut it would be huge wait times. I find it interesting that relaunching the app stops the error momentarily. It certainly seems like a resource is getting filled up so to say..

  • link
    Team
    Oct. 23, 2020, 12:14 p.m.
    link

    Interesting, If you change the settings to save the output to a file what size is the file?

    How much free memory does the system have when it starts to become jerky?

    The only time I saw something like this was with a raspberry pi 3 and I had to disable the live update.

  • call_merge

    The Inkcut Error: Gets Slow & Glitchy after est.1.5 min of Cutting thread has been merged into this thread.

  • link
    Members 10 posts
    Oct. 25, 2020, 1:51 p.m.
    link

    Thank you for your response and diagnoses methods! So - I did the output to a file which ended up being 53.2kb in size. The original SVG I used to produce that file is 110kb.

    My RAM memory seemed unfazed - it literally did not budge at all during the file export. I tried to cut a decal (instead of output to file I sent it to plotter) and RAM memory was the same - unfazed. It sits with a usage of 717mb out of 8gb.

    I tried cutting a new style decal yesterday and found it is literally after about 1 minute of cutting that it becomes slow. It did not seem to be slow when it generated the output to a file - it only took a split second to make the file...

    I could make a video if it is any help. I recorded the terminal output of a successful cut - then I observed the difference between that output and the output during the slow point - there seems to be no difference. What is done here: I launch inkcut, then initiate *send to device cut command. When the cut is done, I exited inkcut.

    The forum would not let me post the entire output so I dropped it into a Google doc:
    docs.google.com/document/d/1ofyDTsuUadlnZ8wpdcbXDlXriFrKKB-e1ydUZNOlXOA/edit?usp=sharing

  • link
    Members 10 posts
    Oct. 25, 2020, 1:59 p.m.
    link

    I have tried many different graphics with the same problem reoccurring - so it is not graphic related.
    I have tried many drivers and driver options - it seems unfazed given driver changes.
    I noticed it happens whether I tell inkcut to make several copies of one graphic, likewise - if I manually create copies of the graphic within a single SVG and give that to inkcut - the exact issue takes place that would if I had used 1 graphic and had inkcut duplicate it.

    In all of my experiments I have not been able to budge or change the results at all. The machine cuts flawlessly otherwise. I just finished an order - a tribute decal I made, I had to make more than 30 copies of the graphic. One cut circuit of the graphic takes about 50 seconds - the machine moves fast, smooth, and rather flawless.

    However - for all of those decals, I had to launch inkcut, perform the cut of one graphic, then restart inkcut to cut the next - I literally did one graphic at a time. This method worked ok even so it took a lot of my time initiating every cut instance.

    Then - yesterday, I tried to upload a different tribute sticker design which was rated to take more than a minute to cut, and sure enough - after a minute or so of cutting the decal the drastic decrease in performance kicks in randomly.

    The theory it could be related to the live view is one I would not doubt, as the hesitation it has during its slow point resembles that of a communication error, for example if there was communication between the computer and printer, but the printer was delaying in sending response, or the inkcut app was slow at decoding.

    When it slows down I can see it operating basically in 'slow motion' pen up, pause, reposition, pause, pendown, pause, perform cut, pause, pen up, pause...

  • link
    Members 10 posts
    Oct. 25, 2020, 3:16 p.m.
    link

    Another thing - before I got into Inkcut I had tried the tool called Signcut in Windows, and I did not have this same issue. I primarily make decals for fun - I don't own a business or generate revenue, so I was hopeful for a opensource utility such as Inkcut. I had thought about trying Inkcut from Windows just to see if there is any difference. On that note - I currently have Inkcut on Debian Linux, it is a very similar setup to a Raspberry computer setup, however instead of the Raspberry computer and systems I used an old spare laptop I had and Debian Linux...

  • link
    Members 10 posts
    Oct. 25, 2020, 3:33 p.m.
    link

    I noticed this on the web: github.com/inkcut/inkcut/issues/182

    "On a short job, everything is fine.
    On a long job, if fails somewhere before the end."

    Although my error is a little different (it is not simply stopping before the finish) it is similar in that small cuts are fine but long cuts are not. Perhaps a similar error to this is happening for me, however the output is different, where for them the cut was ending, maybe around the time mine becomes glitchy..

  • link
    Members 10 posts
    Oct. 25, 2020, 4:41 p.m.
    link

    Another observation I have made is that the terminal debug output of a cut being performed moves very quickly while the plotter is working at full speed, and randomly when it slows - the terminal output also slows. I have tried increasing the USB buffer and it hasn't seemed to make any difference..

  • link
    Members 10 posts
    Oct. 25, 2020, 5:05 p.m.
    link

    Another thing I tried today - along with adjusting USB buffer rates, is running inkcut as root - to see if there were perhaps permission errors, however the exact same thing happens when ran as root as what would happen being run as a user.

    1) Driver doesn't seem to be the issue
    2) USB buffer doesn't seem to be the issue
    3) Graphic SVG design doesn't seem to be the issue
    4) User permissions do not seem to be the issue
    5) Exports to a file fine
    6) Performs short cuts fine
    7) No hint of RAM errors
    8) Issue is consistent (after about a minute of cutting, very glitchy)

  • link
    Team
    Oct. 26, 2020, 11:55 a.m.
    link

    Thanks for sticking with this! I ran a test locally and the problem is the serial monitor becomes slower and slower as time goes on.

    If you can find this file on your system github.com/inkcut/inkcut/blob/master/inkcut/monitor/view.enaml#L71-L74 and comment out those lines (by adding a # at the beginning) then the problem goes away (in my test at least).

    It should look like this:

    func watch_input(change):
        if not plugin.input_enabled:
            return
        widget = comm_log.proxy.widget
        try:
            msg = change['value'].decode()
            #widget.moveCursor(QTextCursor.End)
            #widget.insertPlainText(msg.strip() if plugin.strip_whitespace else msg)
            #widget.moveCursor(QTextCursor.End)
            #scroll_to_end()
        except:
            pass # Ignore decode errors

    The monitor will stop working until I find a real solution.

  • link
    Team
    Oct. 26, 2020, 12:57 p.m.
    link

    A proper fix is in github.com/inkcut/inkcut/pull/285, if you copy that file (or reinstall from git) it should be fixed (at least worked fine or a 12 minute job).

    Thanks!

  • link
    Members 10 posts
    Oct. 26, 2020, 1:43 p.m.
    link

    Thank you!! Yesterday I had begun to wonder if it was a problem with the serial connection. I was researching printer management in Linux and preparing myself for a possible CUPS adventure... I am going to be trying these changes later today very excited!

  • link
    Members 10 posts
    Oct. 27, 2020, 1:46 p.m.
    link

    IT WORKS!!!!! So excited LOL - frmdstryr - you're a saint man! My hero!! I changed out the file with the one on Github you sent and performed a few cuts and it simply worked. Very happy - I'd like to contribute someway if I can please let me know how I could do so (??donation??) thank you!!!