Missing Program Export Variables
LarsWust opened this issue · comments
Steps to reproduce:
- Go to Sandify website
- Export default circle packer as .gcode (issue appears for other formats as well)
Issue:
Resulting .gcode doesn't include program export variables (eg. Machine Type, Machine Radius)
sandify.gcode:
;
; File name: 'sandify2'
; File type: gcode
;
G1 X234.513 Y499.520
G1 X234.513 Y499.520
G1 X233.257 Y498.499
...
Something like what I'm expecting:
; Created by Sandify
; https://sandify.org
; Version: 0.2.8
;
; Machine type: Polar
; Max radius (mm): 250
; Start point: none
; End point: none
; Content type: shape
; Layer:
; Shape: Polygon
; Name: polygon
; Number of sides: 4
; Round corners: false
; Visible: true
; Initial width: 33
; Initial height: 33
; X offset: 0
; Y offset: 0
; Rotate (degrees): 0
; Reverse path: false
; Number of loops: 10
; When transforming shape: smear
; Scale: true
; Scale (+/-): 100
; Scale by: constant
; Spin: false
; Track: false
; Fine tuning:
; Connect to next layer: line
; Draw portion of path (%): 100
; Backtrack at end (%): 0
; Rotate starting point (%): 0
; Reverse export path: false
;
; File name: 'sandify'
; File type: gcode
;
G1 X273.335 Y273.335
G1 X220.832 Y279.168
G1 X214.998 Y214.998
...
Since the 1.0 release, layer/shape settings have been removed from export formats, and are now exported via "File, Save As...", which creates a .sdf file which can then be loaded into Sandify using "File, Open..."
Ah-- I see. Thank you for the clarification! I do have one concern: let's say I have a 250mm radius polar machine, and I share a few gcodes with some of my friends, each with a different radius machine. They would all have to know the original radius of my gcode so that they could scale the design to fit their machines. Of course, I could just tell them the size of my table, but if I'm implementing this system in a user-friendly mobile app, it seems a bit cumbersome for any user to just "know" the original size of any gcode without it being included in the gcode itself. This is mainly just opinion, but I've found that having machine details in exported files has been a very useful feature for importing designs, especially to designate if a design is on a rectangular or polar machine since not all imported gcodes are designed by a user for their own machine.
The exported SDF file actually has a "machine" section at the bottom with the current (at time of export) machine settings. So, you could export multiple times with different machine values. When someone imports a pattern with embedded machine settings, Sandify adds a temporary machine to the "Machines" tab to display the imported pattern. They then have the option of saving that machine permanently by renaming it (or selecting a different machine, etc).
Thank you for the response and sorry for my late reply. I got busy with some other things this week. I understand now that if I just wanted to hypothetically email a pattern to my friend, I could just send the .sdf file and all would be fine and dandy. My predicament however is in a mobile app I'm working on where users can import .gcode, .svg, or .thr files to send to their machine over WiFi. The app used to just read the comments of the imported file so it could scale it correctly, but now there's no way of knowing unless the user is instructed to set their machine size in sandify (which isn't all that bad but I'm just trying to make the process user-friendly/foolproof and could also have issues if users send each other the .gcodes instead of .sdfs). I see why a lot of the comments were moved to a separate .sdf file but in my preference it'd be nice just to have a few lines on the scale of the pattern eg:
;
; File name: 'sandify2'
; File type: gcode
; Machine type: Polar
; Max radius (mm): 250
The gcode import doesn't use the machine size or the pattern from the comments. It uses the gcode pattern itself.
Did the v1.0 update change the way the scaling works for gcode import or export?
@jeffeb3 If I am understanding correctly, they have their own mobile app that relied on the comments.
@bobnik Yes, this is correct. What are your thoughts on bringing the machine size comment back to pattern exports?
I'd be open to adding in a feature like that.
Even though the gcode is for machine reading, I consider the comments (and the gcode, mostly) to be human readable. It isn't a huge sacrifice to have the machine properties in the comments, but how many people will use this?
Can you tell me more about the app and what it does? I am very willing to work with you on making it work (and sandify is MIT licensed, so we are open and business friendly). I just want to take a minute and make sure we're doing it the right way, and we don't have to do it twice. In this case, I am willing to talk in a DM if that makes you more comfortable.
Thank you @jeffeb3 I appreciate the help! I originally didn't plan on using the comments for the pattern machine size, or having a mobile app controller at all. I was just going to put al the .gcodes on a microSD and call it a day. But feature creep got the best of me, so I decided to make my machine as user-friendly as possible with an app in the case I wanted to make more and sell them for pretty cheap to family/neighbors, and that user-friendliness urged me to use the comments in the .gcodes to scale pattern sizes. When I started working on the table and app, I knew nothing about programming so it's been a big learning process.
I've been working on the app (using Flutter) for a few years on-and-off and I've got a little design sharing system where users can view the most "saved" designs along with queues/playlists and a BLE/WiFi remote to work with an esp32 and Firebase. I settled on the name "Tottori" after the sand dunes in Japan (zen garden sand homage kinda thing) and can send some screenshots later. I also plan on making some file protocol to sync LEDs with different patterns, but I'm not quite there yet.
The app is semi-functional right now and I rewrote the whole thing last summer since the first app was a very messy code-learning experience. I could go pretty in-depth about the whole app but it could go beyond the scope of this issue thread so I'm willing to DM or make a v1e thread.
That's awesome. I was at Open Sauce this weekend and there was a lot of interest in project/open source sand tables there. It is so great to see people so passionate about making new things.
Sharing the patterns is definitely something that could use a good solution. Sisyphus has a community website, but it is tricky to use when you're not using their mobile app, and it's only for polar thr formats. We tried briefly to use github for that, but that stagnated pretty quickly. The v1e forums have a few posts with shared files, but not that much in the larger scheme of things.
I can see how (when sharing) the machine size is pretty different between tables. Sandify "solves" this when you import gcode (or .thr) by just scaling the whole thing as big as it will fit, while keeping the aspect ratio. Then you can adjust the height/width how you like for your machine.
I could also see you solve it in your import dialog in Tottori. If the .gcode has the machine size, then you can use it. if not, then you could add some fields in the dialog. Definitely not as slick as automatically reading it.
Adding back in the machine size is possible. I haven't thought through all of the parameters. I don't want to go back to commenting everything. I can believe that machine size may be unique and be useful there. I haven't looked into how hard it would be (does the export code know the machine size, it probably has to). But at best, it is lower priority, but a pretty small thing to change. What do you think, Bob?
@jeffeb3 Yes, it's a small change. I'm reopening this issue so it will stay on our radar.