176

Re: print gcode files to miniMaker

Thins have been quiet for a while, but I am still working on this.  I have reorganized the UI to make things a bit more logical.  Now common functionality is on the left, and functions that only apply to the mini/micro are on the right. 

The more important work has been behind the scenes trying to reorganize the code to make wireless functional.  To that end I removed the helper thread from the UI and added in a child dialog that can handle processing of action and print commands.  I have that all stubbed in but it could use a cleanup.  The big task that is left is breaking all the calls into my xyz library into sub functions that can be pumped rather than blocking.

My wireless card is acting up more and more, if I leave my mini w machine on for more than a few hours the wireless adapter will lock up.  I suspect that the adapter is overheating, I need to pull it out and check the temps.  Anyway the good news is hopefully everyone elses machine works better than mine, mine is horribly unstable!

Anyway I checked what I have done so far in, but you probably don't want to mess with the UI for a while.  I'm hoping to solidify things in the next few weeks and make a new release.  At that time wireless may be workable, but not necessarily stable.  Actually wireless works ok now if you don't use the UI.  The nature of UI being what it is, I need to talk to the printer a lot more and so it tends to mess up quicker.

http://soliforum.com/i/?r2HF6gX.png

177

Re: print gcode files to miniMaker

So my filament guide tube seems to be holding up well. I left the same spool loaded for a month without the filament snapping.  However when I went to unload the filament it did come apart in three places, but I was able to fully unload the filament before it broke so that is progress.  The weather here has been so humid that may be part of the issue.

I still need to redesign the guide tube, once I stop playing around with my miniMover app...

178

Re: print gcode files to miniMaker

Hi everybody I am new to windows and have been trying to 3d print something for 2 week now and can't get figure out how to get a gcode into the 3w file. I sold my macbook which I had a very good system of using threedub in the terminal to do it. I have tried out minimover to do it and it just says process failed whenever I try to convert it and and everything else fails when I plug in the printer and try things. I need some good help here as I have been a mac user my whole life and would really like to 3d print something very soon. Thanks everybody!

179 (edited by carl_m1968 2018-08-22 11:35:14)

Re: print gcode files to miniMaker

charlesmillhollin wrote:

Hi everybody I am new to windows and have been trying to 3d print something for 2 week now and can't get figure out how to get a gcode into the 3w file. I sold my macbook which I had a very good system of using threedub in the terminal to do it. I have tried out minimover to do it and it just says process failed whenever I try to convert it and and everything else fails when I plug in the printer and try things. I need some good help here as I have been a mac user my whole life and would really like to 3d print something very soon. Thanks everybody!

Since you seem impatient and double posted, I am going to ask an obvious question.
Have you installed the normal printer software and confirmed that windows and the PC can see and talk to the printer? Nothing is going to work if there is no talking and you may need drivers installed as well. Since you are new to Windows Google Windows drivers to understand what they are and do. Windows will need them for nearly any hardware you install and most of said hardware supplies those drivers with it's software.

Printing since 2009 and still love it!
Anycubic 4MAX best $225 ever invested.
Voxelabs Proxima SLA. 6 inch 2k Mono LCD.
Anycubic Predator, massive Delta machine. 450 x 370 print envelope.

180

Re: print gcode files to miniMaker

carl_m1968 wrote:
charlesmillhollin wrote:

Hi everybody I am new to windows and have been trying to 3d print something for 2 week now and can't get figure out how to get a gcode into the 3w file. I sold my macbook which I had a very good system of using threedub in the terminal to do it. I have tried out minimover to do it and it just says process failed whenever I try to convert it and and everything else fails when I plug in the printer and try things. I need some good help here as I have been a mac user my whole life and would really like to 3d print something very soon. Thanks everybody!

Since you seem impatient and double posted, I am going to ask an obvious question.
Have you installed the normal printer software and confirmed that windows and the PC can see and talk to the printer? Nothing is going to work if there is no talking and you may need drivers installed as well. Since you are new to Windows Google Windows drivers to understand what they are and do. Windows will need them for nearly any hardware you install and most of said hardware supplies those drivers with it's software.

So sorry I didn't notice I double posted. Google chrome did this to me on my mac too for some reason. I really appreciate your help and I didn't mean to seem impatiant. I have installed xyzware and my computer seems to be talking to the printer and I can start a print from xyzware. I do understand the use of drivers and I am fairly sure I have all needed. I really appreciate your help and am sorry if I sounded rude.

181

Re: print gcode files to miniMaker

Sorry to hear you are having troubles Charles.  Can you go into more detail on what you have tried?

The simplest test would be to slice a stl file in xyzware and save it out as a .3w file.  Then using either minimover or minimoverUI you can convert that to a gcode file, then back to a .3w file and verify that you can in fact load the .3w file into xyzware and print it.

If that works then try going on step further and directly print the .gcode file via minimover or minimoverUI.

Finally you can try slicing a stl file to gcode using cura or your favorite slicer and then see about pushing that to the printer via minimover.

In any event we could use a lot more details.  What printer do you have, what version of minimover are you using.  Are you using the command line or UI (window) version.  What files are you trying to print and what error are you getting. 

If nothing works for you then post the files here and I can try to print them to verify they are in good shape.

182

Re: print gcode files to miniMaker

david.tucker wrote:

Sorry to hear you are having troubles Charles.  Can you go into more detail on what you have tried?

The simplest test would be to slice a stl file in xyzware and save it out as a .3w file.  Then using either minimover or minimoverUI you can convert that to a gcode file, then back to a .3w file and verify that you can in fact load the .3w file into xyzware and print it.

If that works then try going on step further and directly print the .gcode file via minimover or minimoverUI.

Finally you can try slicing a stl file to gcode using cura or your favorite slicer and then see about pushing that to the printer via minimover.

In any event we could use a lot more details.  What printer do you have, what version of minimover are you using.  Are you using the command line or UI (window) version.  What files are you trying to print and what error are you getting. 

If nothing works for you then post the files here and I can try to print them to verify they are in good shape.

Thank you for helping me. I am using a da vinci jr 1.0 with stock firmware. I have minimoverUI 0.9. I never tried the command line version. I have Cura exporting a .gcode file using the da vinci jr cura profile from kr15_uk. I am exporting the .gcode to my desktop then opening minimoverUI and clicking the convert file button, selecting desktop then selecting the .gcode and then on the other dropdown menu selecting the gcode files instead of the all files then I try to save it to my desktop with the name benchy.3w then clicking the xyz files instead of the all files then it shows the minimoverUI app and at the bottom it says process failed. This is really cool application and I am going to be very excited when I get mine to work because this is a really really cool idea and great work! Thanks for helping me!

183 (edited by x1800MODMY360x 2018-08-23 04:21:17)

Re: print gcode files to miniMaker

charlesmillhollin wrote:
david.tucker wrote:

Sorry to hear you are having troubles Charles.  Can you go into more detail on what you have tried?

The simplest test would be to slice a stl file in xyzware and save it out as a .3w file.  Then using either minimover or minimoverUI you can convert that to a gcode file, then back to a .3w file and verify that you can in fact load the .3w file into xyzware and print it.

If that works then try going on step further and directly print the .gcode file via minimover or minimoverUI.

Finally you can try slicing a stl file to gcode using cura or your favorite slicer and then see about pushing that to the printer via minimover.

In any event we could use a lot more details.  What printer do you have, what version of minimover are you using.  Are you using the command line or UI (window) version.  What files are you trying to print and what error are you getting. 

If nothing works for you then post the files here and I can try to print them to verify they are in good shape.

Thank you for helping me. I am using a da vinci jr 1.0 with stock firmware. I have minimoverUI 0.9. I never tried the command line version. I have Cura exporting a .gcode file using the da vinci jr cura profile from kr15_uk. I am exporting the .gcode to my desktop then opening minimoverUI and clicking the convert file button, selecting desktop then selecting the .gcode and then on the other dropdown menu selecting the gcode files instead of the all files then I try to save it to my desktop with the name benchy.3w then clicking the xyz files instead of the all files then it shows the minimoverUI app and at the bottom it says process failed. This is really cool application and I am going to be very excited when I get mine to work because this is a really really cool idea and great work! Thanks for helping me!

to convert gcode to ----> 3w for minimover app the printer must be on and connected to the app.

also the app don't like when you change the filename when converting like "test.gcode" to "alpha.3w"

must be "test.gcode" to "test.3w" etc.

184

Re: print gcode files to miniMaker

I have not had a lot of free time recently, but last night I managed to get one of the functions working under my new scheme.  I'm going to spend a few days cleaning it up and then apply the same scheme to the other functions.  Hopefully I can have something working in a week or two.

On a side note it seems that some store is dumping all its Da Vinci Jr Pro models on ebay.  There is even one going for only $100.  I'm very tempted to pick it up however it is not sufficiently different from the mini models for me to justify buying it.

185 (edited by david.tucker 2018-08-25 18:36:11)

Re: print gcode files to miniMaker

x1800MODMY360x wrote:

to convert gcode to ----> 3w for minimover app the printer must be on and connected to the app.

also the app don't like when you change the filename when converting like "test.gcode" to "alpha.3w"

must be "test.gcode" to "test.3w" etc.

You don't have to have the printer connected, but then I can't auto detect the model so I won't be able to convert the file unless you manually select your printer from the target dropdown.  I probably should detect that case and pop up a message telling you to select the printer by hand.

In the UI I can't reproduce the issue with changing names during conversion, I can go from source.gcode to target.3w just fine.  Maybe that does not work on the command line version?  I will try to test that out.

186 (edited by david.tucker 2018-08-26 07:12:08)

Re: print gcode files to miniMaker

Ok, I managed to clean up the calibration routine, now if you are not on wifi I never block, so the UI remains very responsive.  For now I have to make a small block on wifi, but I can probably remove that at some point in the future.  Does not matter since wifi is such a turkey...

Anyway I need to clean up the rest of the functions to follow this new scheme.  It should go smoothly, now that I have a framework in place.  For now here is a peak into the process.  This is the main 'polling' loop that keeps track of state and moves the process of calibrating along without blocking.  I tried to keep it as clean as possible, but it is still much more messy than the old blocking routines.

// call in loop while true to pump status
bool XYZV3::calibrateBedRun()
{
    debugPrint(DBG_LOG, "XYZV3::calibrateBedRun()");

    switch(m_actState)
    {
    case ACT_FAILURE:
        //something went wrong
        break;
    case ACT_CB_START: // start
        if(serialSendMessage("XYZv3/action=calibratejr:new"))
            setState(ACT_CB_START_SUCCESS);
        else setState(ACT_FAILURE);
        break;
    case ACT_CB_START_SUCCESS: // wait on success
        if(isWIFI() || checkForJsonVal("stat", "start"))
            setState(ACT_CB_HOME, 120);
        else if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_HOME: // wait for signal to lower detector
        if(!isWIFI() && checkForJsonVal("stat", "pressdetector"))
            setState(ACT_CB_ASK_LOWER, 240);
        else if(isWIFI() && checkForState(STATE_PRINT_CALIBRATE, 41, true))
            setState(ACT_CB_ASK_LOWER, 240);
        else if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_ASK_LOWER: // ask user to lower detector
        // waiting, nothing to do
        if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_LOWERED: // notify printer detecotr was lowered
        if(serialSendMessage("XYZv3/action=calibratejr:detectorok"))
            setState(ACT_CB_CALIB_START);
        else setState(ACT_FAILURE);
    case ACT_CB_CALIB_START: // wait for calibration to start
        if(isWIFI() || checkForJsonVal("stat", "processing"))
            setState(ACT_CB_CALIB_RUN, 240);
        else if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_CALIB_RUN: // wait for calibration to finish
        if(!isWIFI() && checkForJsonVal("stat", "ok")) // or stat:fail
            setState(ACT_CB_ASK_RAISE, 240);
        else if(isWIFI() && checkForState(STATE_PRINT_CALIBRATE, 44, true))
            setState(ACT_CB_ASK_RAISE, 240);
        else if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_ASK_RAISE: // ask user to raise detector
        // waiting, nothing to do
        if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
        break;
    case ACT_CB_RAISED: // notify printer detector was raised
        if(serialSendMessage("XYZv3/action=calibratejr:release"))
            setState(ACT_CB_COMPLETE);
        else setState(ACT_FAILURE);
        break;
    case ACT_CB_COMPLETE:
        if(isWIFI() || checkForJsonVal("stat", "complete"))
            setState(ACT_SUCCESS);
        else  if(m_timeout.isTimeout())
            setState(ACT_FAILURE);
        //else loop
    }

    m_progress = 100 * (m_actState - ACT_CB_START) / (ACT_CB_COMPLETE - ACT_CB_START);

    // return true if not error or done
    return m_actState != ACT_FAILURE && m_actState != ACT_SUCCESS;
}

187

Re: print gcode files to miniMaker

Would anyone have any ideas why the Serial num: does not display correctly on a KR with firmware 2.2.0? This is what it is showing up as in miniMaker 3F1J0P������������




http://soliforum.com/i/?WeIvzVB.png

188

Re: print gcode files to miniMaker

Bozotclown1970 wrote:

Would anyone have any ideas why the Serial num: does not display correctly on a KR with firmware 2.2.0? This is what it is showing up as in miniMaker 3F1J0P������������




http://soliforum.com/i/?WeIvzVB.png

The model number I’m reporting matches that of a mini w. The number you mentioned is for a jr 3 in one machine. What mashing do you actually have?

189 (edited by david.tucker 2018-08-28 05:23:44)

Re: print gcode files to miniMaker

I managed to get all but one action command converted over to the new system. That does not eliminate all sources of blocking but does get rid of the worst offenders.

I still need to convert printing and firmware upgrades to the new system. And I only roughed in progress bar support and state tracking. Also I’m not being very smart about error handling, I’m lumping all errors together and not really keeping track of things. I could early out a lot faster if I tracked the errors better.

Anyway I need to retrofit this onto the command line version then I will check in my progress. I still have a few weeks of work before the next release can come out but at least it is getting closer.

I also need to go back and test WiFi again but I’m loathed to do it. It is frustrating how unstable things are.

190

Re: print gcode files to miniMaker

david.tucker wrote:
Bozotclown1970 wrote:

Would anyone have any ideas why the Serial num: does not display correctly on a KR with firmware 2.2.0? This is what it is showing up as in miniMaker 3F1J0P������������

The model number I’m reporting matches that of a mini w. The number you mentioned is for a jr 3 in one machine. What mashing do you actually have?


David,

Thanks for the reply, it is a JR with firmware 2.2.0.

191

Re: print gcode files to miniMaker

Bozotclown1970 wrote:
david.tucker wrote:
Bozotclown1970 wrote:

Would anyone have any ideas why the Serial num: does not display correctly on a KR with firmware 2.2.0? This is what it is showing up as in miniMaker 3F1J0P������������

The model number I’m reporting matches that of a mini w. The number you mentioned is for a jr 3 in one machine. What mashing do you actually have?


David,

Thanks for the reply, it is a JR with firmware 2.2.0.

Try downloading the 0.9 release of mini maker. The head branch is unstable right now. If that does not work then may I ask you to run some test code for me.

192

Re: print gcode files to miniMaker

I do not believe it is a software issue. I believe it has something to do with either the firmware or the EEprom. What test would you like run?

193

Re: print gcode files to miniMaker

Bozotclown1970 wrote:

I do not believe it is a software issue. I believe it has something to do with either the firmware or the EEprom. What test would you like run?

Can you run the command line command miniMover -r and send me the output (or post it here). That is a raw dump of the status message from your printer.  If that has the wrong serial number then the problem is definitely in your firmware.

Can I ask, how is the printer working otherwise, can you print using XYZWare, how about printing with miniMaker.  It could be they messed up a recent firmware update and just embedded the wrong serial number but the bug is benign.

194

Re: print gcode files to miniMaker

Time for another update. I have all the action commands working ok, but the ui could use work. I’m moving over to the print and convert commands since that is the more difficult problem to solve. I have both stubbed in but they block so the ui locks up till they finish.

I thought I’d make a to do list to keep me motivated

  • split file conversion up so we can pump it

  • split file upload up so we can pump it

  • make a print monitor routine and drive the ui

  • tweak all progress bar timings

  • have xyz lib return state string

  • test WiFi, probably need to slow down polling by a lot!

  • reduce timeouts

  • poll for state when on usb

  • add in proper error handling

  • look over latest xyzware for new printer defines

  • eliminate the remaining sleep

  • eliminate the remaining waits

Most of that is just grunt work however dealing with error states is tricky. Right now I assume that all functions only return two states but really we have three states. Those are success, failure, and keep trying. The failure state should probably be global and once set will take a machine cycle to clear out. I need to think some more on that.

195

Re: print gcode files to miniMaker

Right now the xyz lib is still written in a procedural way where you make individual calls for every action. However the underlying logic is heading towards a state machine. I’m tempted to convert the whole thing to a giant state machine internally. That may be needed if I plan on eliminating all blocking calls.

State machines are great once you get them working but they make your head hurt when trying to developer them.

196

Re: print gcode files to miniMaker

It occurred to me tonight that I need to take a closer look at combining commands together. There are times when you can query status while another command is executing. I have a rough map of how xyzware handles things but I should work out exactly when it is ok and not ok to update status.

I also need to experiment with timing on WiFi. I think part of the instability there comes from stacking commands too close together

197

Re: print gcode files to miniMaker

I was suppose to be working on removing blocking in the file/print routines but that sounded like real work so I skipped out on it.  Instead I have been working on error handling.  I managed to clean up error handling quite a bit, things should be a lot more graceful when a connection drops.

I also found a race condition where the status box was updating when my sub dialog was attempting to run an action command.  On serial (USB) this seems to be relatively safe but on wifi the connection is very fragile and this caused real issues.  Anyway I have it cleaned up now.

Anyway the upshot is that I was able to calibrate the printer over wifi without it locking up.  There may be more issues hiding in there but at least there is promise for wifi.

Back to the slog, I still need to work up the nerve to unblock the file routines.

198

Re: print gcode files to miniMaker

Ok, I managed to split the file upload routines apart, and got the new print monitor running.  Things are getting close to ready for the next release. Anyway the next step is to split up the file convert routines and better handle error states.

199

Re: print gcode files to miniMaker

Ugh, wifi is still such a mess!  I had to put in a 500 ms delay between each communication with the printer just to make it stable, and even then it is not perfect.  I'm thinking I will need to add a delay deep in the wifi code to ensure we don't communicate too fast.  The reverse is just as bad, if I don't send data often enough it just locks up as well.

200

Re: print gcode files to miniMaker

Spent some time cleaning up wifi, I think there is hope in the far off distance for this.  I had misunderstood how select worked, now it should work better.  I was able to remove all the sleeps in the xyzv3 lib and in the miniMoverUI project.  And with some creative extensions of the delay routines I think I have managed to stabilize things better.

Anyway there is no way to know if I got it right other than to obsessively test every possible permutation over wifi.  Now I'm off for a busy week of testing.