Dave K

Forum Replies Created

Viewing 23 posts - 1 through 23 (of 23 total)
  • Author
    Posts
  • #102140

    Dave K
    Participant

    Well, how about that…  I’m using 1.1.9 for a totally unrelated 3D printer setup, and thought that 2.0 was only needed for dual endstops for some reason, which I do NOT have at this point.  I just used the files downloaded from the MPCNC page.  But, checking the two configuration.h files does seem to confirm that the MPCNC is on 2.0.  Sorry for the confusion.

    So, now, the question becomes a different one:  Is there someplace to learn how to program the “custom” buttons on the LCD display?

     

    #102131

    Dave K
    Participant

    Is that true in 1.1.9?  Or only 2.0?  I could not tell from reading this thread, given my lack of Marlin expertise…:-)

    #102119

    Dave K
    Participant

    Does anyone know if  Karl’s LCD display mods work with the “standard” MPCNC Marlin 1.1.9?  I’m not ready (and don’t have any need) to switch version 2, but have thought that many of the changes that Karl has done would be useful.  Thanks.

    #100310

    Dave K
    Participant

    Did you write your own TFT customization?  Or is there one “out there” someplace for the MPCNC?  I have one to try out on my MKS Gen L version of the MPCNC, but would prefer to start with an existing interface if something is available.  (Currently running with the simpler graphics display)

    Also, have you tried the WiFi that these TFT displays support? I’m wondering what functionality that offers,  if any.

    #100309

    Dave K
    Participant

    As stated here and a couple of other places, the MKS Gen L board works fine.  Mine been up and running for several months on my MPCNC.  A few quick things.

    1. Just use the Marlin version from here that is set up for the RAMPS.  You’ll need to change the MB name as mentioned above.

    2.  You will need to get a specific serial driver for this board in order upload your marlin.  I don’t have it handy, but it’s mentioned elsewhere in this forum.  If you have Windows 10, it may not want to install because it’s not registered or something.  There are instructions on line to temporarily override that.

    3. I use the DRV8825 drivers, but the 2130s should work, I imagine.  There are YouTube videos about using them with the MKS Gen L for 3d printers.  Same exact process.  I did note that one of those TMC drivers gets quite hot  so make sure you have adequate cooling.  Don’t be tempted to get fancy. Just use them in legacy mode or whatever is simplest.  Vref will be set differently than for the DRV8825.  You don’t have to worry about the types of printing artifacts that you do with 3D printing.  And, you won’t know they are quiet because you are running a router!!  🙂

    4.  You connect the dupont connectors from the stepper motors directly into the MKS.  Main power is obvious.  USB is obvious. Only other thing is the end stops.  For z-only, it’s obvious .  I think the firmware is slightly different if you are using dual endstop for x and y, but someone else will know.

    5.  If you use the Reprap Discount Full Graphics display (or whatever its called) you will need to reverse the ribbon cable connectors.  Info on YouTube and above.

    6.  You can also use the MKS TFT displays.  They don’t require any firmware settings, but you’ll need to customize separately.  I’m about to try this, as I have the Tft24, but I’m not sure if there is any value to doing it.

    Bottom line:  MKS Gen L implements easily and works just fine in the MPCNC application.

    #100305

    Dave K
    Participant

    Are you interested in any specific aspect of the wiring?

    I’ve been using the MKS Gen L board for about 6 months, and it works with no problems.  I use the DRV8825 drivers for all 3 directions.  The stepping motors are attached to the X, Y and Z connectors.  I only use the z endstop for zeroing purposes, and an “always on” fan connector.  All are clearly labeled on the various photos available.

    You do need the serial port driver mentioned above, and the RAMPS version of Marlin.

    For the 64128 display, it just connects into two ribbon cable connectors on the Board, but you may want to get a couple of longer cables  and, yes, you’ll have to reverse the connector housings on the display board.

    You can also use an MKS TFT display, but I’ve not done that yet.

    About the only issue that I’ve had is that the dupont connector for the y motor was not staying connected, so I made a jumper to the JST connector on the Board. Probably could have bent the pins on the Board slightly.

    I’ve also just done a board upgrade on my 3D printer.  The implementation on the MPCNC was much simpler for various reasons.

    #96377

    Dave K
    Participant

    This is indeed, the “holy grail” for those of us who are interested in relief carving.  I’ve been going down the exact same path as Ian and Kelly for the last few weeks since I’ve gotten the MPCNC operating.  I’ve evaluated various software, trying to decide whether or not I needed (or could use effectively) things like PhotoVCarve and Meshcam.  (Aspire is out of the question)  And, like you all, I’ve searched for some evidence that ArtCam  might somehow still be out there.

    So far, I’ve drawn only one strong conclusion, and that is that it is indeed a very difficult problem to automate.  Because the depth information is lost completely, it appears to me that there are two factors that come into play for our human brains as we process these images:  Lighting and color.

    In principle, lighting might be manageable, especially if you can convert to a line drawing such as the Popeye demo guy did in the video referenced in Ian’s blog.  I’ve seen several things that are sort of like that, and for a sort of “cartoon” image, his method looks promising.  The attached example of the chess knight is a possibility.  We know it’s color is uniform, so any apparent variation is due to lighting.  If we had a line drawing, we could probably succeed.  For more complex images, I’m not convinced that it will be reasonable.

    The effect of color is another story.  Simply converting to grayscale is not sufficient if the image is “contrasty” to start with.  Consider the attached image of one of our dogs, Isis.  Converting to greyscale gives you an image that is straightforward to use for a lithophane, for example, because the thicker area that is supposed to be black does indeed transmit less light, so it looks darker.  However, consider what happens when you try to take that same greyscale image and carve it…  We know that the black and white sections of her face are nearly in the same plane, but the computer has no idea that this is true.  Thus, you will get deep holes where her nose and eyes are, as well as the tips of her ears, while the front of her face will be high.  The result is absurd.

    This example is extreme of course, but when I was working with it, I realized the complexity of the problem–color (i.e. tone level) complicates the process as much as lighting does.

    It almost seems to me that converting the photo to a line drawing in some way and then using the grayscale gradient might be the most promising, but I’ve not tried that yet.  I wonder if all these artists around the world are not doing something like that.

    Finally, for anyone who has not tried it yet, you should be aware that you can do a reasonable job of the actual carving of these on-line “x-ray” looking images using ESTlcam.  The process is not quite as simple and flexible as it is using MeshCAM, but if you pull one of those images into something that can generate an STL file, (such as a slicer like CURA) you can then pull that STL into ESTLcam and set up the carving.  This is what made me decide that for now at least, I don’t really need MeshCAM.  At least until the artwork problem is solved…

    #96232

    Dave K
    Participant

    Well, I didn’t even have to try the run… it was obvious in the gcode that this would solve the problem.

    Thanks.

     

    #96203

    Dave K
    Participant

    Well, that’s something to try…those boxes are blank.  Will try it and report.

    #94684

    Dave K
    Participant

    Sorry but now I am confused.  This unit does NOT have dual endstops.  It uses the wiring package that you refer to as “serial” in your store.  That is, the two x motors are driven by a single driver on the controller, and the y motors are driven by another, single driver.   I thought that being individual meant that each motor was directly connected to it’s own driver.  Thus, there is nothing to measure that would be the different between the two motors that vary in temperature.

    What am I missing?

    #94301

    Dave K
    Participant

    Sorry.  I should have mentioned that info   These are wired without the dual end stop, so they are wired in pairs.  (serial?).  That’s why I found it odd that the two motors on the same driver would be that much different.

    Is there any possibility that the belt tension could change the load enough to cause a temp difference?  Obviously, I’ve tried to make that as uniform as possible, but that’s all by feel, so who knows?

    The only obvious difference is the extra wire that crosses through the 2′ wide bed, but the fact that on the other axis they are identical seems to negate that issue.

    In the meantime, is dropping the driver voltage slightly the way to reduce the temperature?

    #93348

    Dave K
    Participant

    I don’t know.  It might.  Is there a way to use it after generating the toolpath/gcode from within Photo Vcarve?  That is, as an independent app? Or something like that?  I don’t see a way to put it inside of PVC.

    #91673

    Dave K
    Participant

    Is there a speed setting someplace beside the tool list?  And, I still don’t understand why ESTLCAM would be different than Repetier, which is a key issue.  How would Estlecam “think” that it should  be one speed, yet Repetier thinks it’s another, much slower speed?

    #91594

    Dave K
    Participant

    I don’t think so.  Now that the problem has been resolved by the reinstall, the projected times are very similar.

    Also, this was just one example.  There were several others in which the numbers were completely different – – 11 hours vs 25 minutes

    #91578

    Dave K
    Participant

    I checked that carefully, but, I don’t think it explains why Estlcam thinks the project will take 5 minutes and Repetier, using the *.nc file from Estlcam comes up with an estimate of several hours.  Wouldn’t we expect that Estlcam would have the same long time estimate?

    The images are screen shots of what I was seeing (and what actually happened) with cutting a simple ellipse that was less that 5″ wide.

    Estlcam estimates a time of 4’25”

    The file is saved and opened in Repetier.

    Repetier estimates 4 hours 34′ 39″

    #91308

    Dave K
    Participant

    As jeffeb3 said, you need to define the “islands” as parts.  This will outline the islands.  Then, if you define the surrounding areas as “holes”, choosing the island format, you should get what you want.

    I personally found this to be exactly backwards, but once you get it, it works with no problems.  I’ve attached one way to do your image.  The blue outlines were the areas that were defined as “parts” first.

    #90413

    Dave K
    Participant

    This is interesting.  If I understand correctly, this would also be useful after a tool change to establish the new zero for Z without changing X and Y.  Right?  I have not tried to do this, but is it possible to send a gcode command while the machine is paused (e.g. in Repetier)?

    Understand that while I have everything running, I have not yet done anything beside draw because I need to fabricate a tool mount.  However, I have been able to control through Repetier, including running the crown image, as well as from the SD card (RepRap smart controller).  I see a button to pause the “print”.  Is this how one does tool changes?   (I do NOT have dual end stops at this time.)

    #90073

    Dave K
    Participant

    Well, this one is just going to be a mystery  I guess, at least for now.  When I went back and connected all the stepping motors, the movement on the z axis is now OK.  I literally didn’t change anything .. Simply went ahead and connected x and y as well as z.  Before, it had been z only.

    In fact  I would think that I had just been mistaken, but I had been able to reproduce the problem exactly multiple times.

    But, now it works   Don’t know why.  Moving on

    Thanks for the ideas.

    #90072

    Dave K
    Participant

    Well, the problem I WAS having was that Repetier would connect to the MKS Gen L V1.0, but in manual mode, the commands would queue but not get executed.   The “No start received” message was mixed in there someplace  Troubleshooting at the Repetier site suggested that this command queuing was due to communication being one way only  (I found similar results when I tried Pronterface, which was also available.)

    Note that my firmware must be OK because I had complete control of the machine using the RepRap discount full graphic display.  So it clearly pointed to some sort of communication problem over the USB.  I checked/corrected the port and baud rate, but no success.  The only suspicious issue was that I had used a USB 3.0 extension cable because the short one that came with the MKS was insufficient.

    This was confirmed when I tried again this morning when I found it possible to connect to Repetier using only the short cable and with no steppers connected.  It was apparent in the log file that the gcode commands were actually getting sent to the MKS, which was not evident yesterday. .

    Connecting everything back up this PM using a longer USB cable with no extension found everything working, and in fact, I was able to nicely print the crown

    Why did it get fixed?  I have no idea  really.  Was it the USB extension?  Maybe, but everything was power cycled and Repetier was closed and restarted.  Bottom line is it’s working   I’m responding here so that there is closure to my inquiry.

    Thanks for your support.

    #89938

    Dave K
    Participant

    Did you ever get Repetier working?  Same problem

    #89893

    Dave K
    Participant

    Good idea to confirm the travel per rotation.  It IS easy to check.

    I also thought about connecting the z-stepper to the x or y driver, which is set for 200 steps per mm since it’s a belt.  That result should point to either the leadscrew or the motor.

    #89891

    Dave K
    Participant

    The first thing I checked was the angular step size.  Specifications at Amazon are clear, but, there was a specification card with the motor.  I should check that too.  From Amazon:

    * Manufacturer Part Number: 17HS19-2004S1
    * Motor Type: Bipolar Stepper
    * Step Angle: 1.8 deg.
    * Holding Torque: 59Ncm(83.6oz.in)
    * Rated Current/phase: 2.0A
    * Phase Resistance: 1.4ohms
    * Inductance: 3.0mH+/-20%(1KHz)

    Physical Specification:

    * Frame Size: 42 x 42mm
    * Body Length: 48mm
    * Shaft Diameter: 5mm
    * Shaft Length: 24mm
    * D-cut Length: 15mm
    * Number of Leads: 4
    * Lead Length: 1m with connector
    * Weight: 390g

     

    As for the jumpers, the MKS Gen L board has jumpers in all three positions.  They’ve not been touched.

    #89821

    Dave K
    Participant

    Well, further investigation revealed a couple of things, and now, it appears that the upload worked.

    1.  The serial port driver is apparently different than the standard RAMPs board.  To be honest, I’m not sure this is correct because I’ve also been planning for an MKS GEN I upgrade to my printer, and I’ve never seen this issue mentioned.  However, I did find a couple of references to the need to install the CH341SER drive from http://www.wch.cn/downloads/CH341SER_ZIP.html
    2. Of course, even that is not so simple, as Windows 10 has “protection” from unsigned drivers, so I had to temporarily turn off “Signed Driver Enforcement” so that this driver would load, which it did.
    3. Apparently, a suitable baud rate for the MKS GEN L board is 115200 instead of the default value.  During one attempt to upload, the baud rate was overridden, so I just changed it.
    4. Finally, (and this may have been the most important??) I had not realized that the com port that was used did not seem to appear until the board was attached.  To be sure, I don’t know if changing that was needed or not–it may have been automatic.

    With all this done, the compile and upload of the MPCNC version of Marlin seems to have been successful…  Next step:  see if the stepping motors will work.

Viewing 23 posts - 1 through 23 (of 23 total)