Close



Page 3 of 9 FirstFirst 12345 ... LastLast
Results 21 to 30 of 84
  1. #21
    Senior Engineer
    Join Date
    Jun 2014
    Location
    Burnley, UK
    Posts
    1,662
    Quote Originally Posted by EagleSeven View Post
    No, the slicer software sends G-code commands to printer, thru the USB port !
    ( .stl to slicer and G-code to printer, that's all that's Needed, Not .x3g )
    Whatever. Go and read some.

  2. #22
    Student
    Join Date
    Dec 2015
    Location
    Charlotte NC
    Posts
    11
    Quote Originally Posted by EagleSeven View Post
    No, the slicer software sends G-code commands to printer, thru the USB port !
    ( .stl to slicer and G-code to printer, that's all that's Needed, Not .x3g )
    While it may be transparent x3g translation, my flash forge / powerspec / makerbot replicator 2 in fact does not understand gcode - this is why you can't use OptoPrint without a translator. Now, the console in s3d will take the gcode you type in, but it's translated before it's sent to the printer. x3g is, from what I understand, a binary format for the text based gcode, simular to how the old Intel 8051AH Basic and Apple II computers use to translate commands (like PRINT or GOTO) into a single binary character that was translated to and from the text counter part at what we would call now the presentation layer.

    As for having multiple pc's, that is definatley an option, but it's not something I want to hassle with - too many points of failure. SD card printing has a higher reliability index than printing from a PC and can easily be managed remotely.

  3. #23
    Engineer-in-Training beerdart's Avatar
    Join Date
    Feb 2014
    Location
    CT
    Posts
    345
    16gb Flashair ordered.

  4. #24
    Quote Originally Posted by AlbertZeroK View Post
    While it may be transparent x3g translation, my flash forge / powerspec / makerbot replicator 2 in fact does not understand gcode - this is why you can't use OptoPrint without a translator. Now, the console in s3d will take the gcode you type in, but it's translated before it's sent to the printer. x3g is, from what I understand, a binary format for the text based gcode, simular to how the old Intel 8051AH Basic and Apple II computers use to translate commands (like PRINT or GOTO) into a single binary character that was translated to and from the text counter part at what we would call now the presentation layer.
    That is true if you are using an SD card, plugged into printer (SD requires .x3g) ,
    but if using a computer thru USB cable connection there is No translation to .x3g involved,
    when using Makerbot or Rep-G slicers, (not sure about other slicers).

    That is what I've read about how it works in our CTC printer,
    I assume other similar printer makes are Same.
    Last edited by EagleSeven; 01-11-2016 at 08:22 AM.

  5. #25
    Senior Engineer
    Join Date
    Jun 2014
    Location
    Burnley, UK
    Posts
    1,662
    The printer only understands X3G so whether or not you use USB or SD the printer still only understands X3G

    If you use Repg to send over USB then RepG translates to X3G before it sends it. RepG is not a slicer it is front end to assist in slicing and talking to the printer. Makerbot Desktop is a slicer (IIRC though I don't use it) and it too converts to X3G before sending it to the SD card or to the printer directly over USB.

  6. #26
    Quote Originally Posted by Mjolinor View Post
    The printer only understands X3G so whether or not you use USB or SD the printer still only understands X3G

    If you use Repg to send over USB then RepG translates to X3G before it sends it. RepG is not a slicer it is front end to assist in slicing and talking to the printer. Makerbot Desktop is a slicer (IIRC though I don't use it) and it too converts to X3G before sending it to the SD card or to the printer directly over USB.
    *** Wrong ***

    Where are you getting this 'Wrong' Information ??

    If you dreamed it, it Don't count !


    Last edited by EagleSeven; 01-11-2016 at 11:27 AM.

  7. #27
    Senior Engineer
    Join Date
    Jun 2014
    Location
    Burnley, UK
    Posts
    1,662
    Quote Originally Posted by EagleSeven View Post
    *** Wrong ***

    Where are you getting this 'Wrong' Information ??

    If you dreamed it, it Don't count !


    You are going to be very embarrassed when you eventually learn how to use Google.

  8. #28
    Quote Originally Posted by Mjolinor View Post
    You are going to be very embarrassed when you eventually learn how to use Google.
    Hey, friend 'Google' is where I got the Correct Info !

  9. #29
    Senior Engineer
    Join Date
    Jun 2014
    Location
    Burnley, UK
    Posts
    1,662
    Like I said, when you learn to use Google you are going to be embarrassed. Perhaps you are one of those unfortunates that believes everything they read on the Internet.

    This is why I am attempting to correct you, it is extremely annoying when one googles for things and the information you find is incorrect.

  10. #30
    Engineer-in-Training ServiceXp's Avatar
    Join Date
    Apr 2015
    Location
    USA
    Posts
    379
    Follow ServiceXp On Twitter Add ServiceXp on Google+ Add ServiceXp on Thingiverse
    Quote Originally Posted by ServiceXp View Post
    Interesting, I've not run into any problems with big files yet, but I've only completed 9 or 10 prints using this method. At what size and what problems are you seeing with this mapped drive method? How long have you been using this method?

    I just thought of a test to see what locks, if any, the firmware is placing on the files being used. I suspect there are no locks and hence the possibility of problem, just not sure of what those problems are. I've written/deleted both files and folders while the machine was printing, and rebooted the machine with the mapped drive, also let it sleep and have not seen any disruptions in the printer. I have not however messed with the current file being printed.
    OK so after a bit of testing/experimenting this is what I've discovered. There are no file locks (at least none that Windows 10 honors) being placed on the current file being printed. Small files (not sure of the size breakpoint here) are completed loaded into memory, and can be deleted from the SD card after the print starts. This worked for the files under 1meg I tested.

    Files over 10 megs:
    1) there are no file locks (at least none that Windows 10 honor) being placed on the current file being printed.
    2) Renaming the file, then renaming back does not effect printing.
    3) Renaming the file and leaving it for 10 seconds does not effect printing.
    4) Coping and pasting the same file that is being printed does not effect printing.
    5) Renaming the file and leaving it causes the print to fail. (as would be expected)
    6) Deleting the file after print has started causes the print to fail. (as would be expected)

    All-In-all, fairly robust all things considered. It would be nice to have some file locks, but......
    Last edited by ServiceXp; 01-13-2016 at 12:03 PM.

Page 3 of 9 FirstFirst 12345 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •