We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
I’d like the ability to create an app that accepts and returns G code. I have a couple of translation apps in mind. But that interface would open up a lot of possibilities.
It would be great if an app could send strings to the com port. Some other users have been requesting macro-ish abilities. The ability would allow an app to define macros and expose their parameters as controls in the app interface window. But that would be reliant on the following…
Apps could have a local storage method on the server. If a macro app was allowed, it could store saved macro definitions in a delimited text file in a space associated with the user id. But many apps would benefit from the ability to persist data across sessions.
Not sure what you are looking for but i found a way to be able to configure my own macros and upload them to this sender and attach them to the buttons. I think if you get creative you can find ways to do almost anything you want.
I’m just spit balling here. But what if a driver was written that exposed a com port that directed all communication to an intermediary device like a raspberry pi. The Arduino would be connected to a different usb port on the raspberry pi. And said pi would act as a pass thru. But could also be commanded to create g code commands and send them on to the Arduino.
It wouldn’t be too difficult to write a driver for windows that would get the com port data to the Pi. But I doubt that a driver for the arduino exists for the Pi. And I have zero experience writing drivers in Linux.
I was hoping to add other features to the PI intermediary to help justify its existence: code buffering with “resume from fault”, code translation: adjust the position, rotation and scale of the g code coming thru; any type of post processing, maybe add textures to pockets… But I accept your point in the spirit of “too many cooks in the kitchen” with the PI being the one cook too many.
You make an excellent point regarding the COM ports. It wouldn’t be surprised if what you suggest was already on a best practices somewhere. Regardless, it shouldn’t be difficult to relocate Easel’s com port code; possibly a very quick fix.
