Wow Benendikt, that is a heck of a undertaking.... Im not familiar with pandora so i will be no help, is the goal just the front end and leaving the FPGA alone for motion? or is it a full new rewrite? Are you basing any of it off of LinuxCNC or UCcnc for motion path planning? I'm trying to just better understand how this controller works as it seems to mirror more expensive controllers functions i.e standards. Meaning if i can figure out how to write a M98 sub on this I should be able to do it on a Siemens etc as they should respond the same. Have you seen the feature set of the AU based HIND this would be a good reference for UI and features.. basically the same idea but the DDCSV is 1/4 the price and has better hardware. We could really do something with this if we can get this worked out. Thanks for all your work on this Benedikt... Im happy to help where i can and test as well
I have seen the Hind controller. Interesting project.
Back to the DDCSV, which is now called Pandora (the modded firmware). Initially I wanted to do a full rewrite and I started writing some software and it ran, but I ran out of spare time to reverse-engineer the driver (just yet, this will be done eventually!). So my current goal is to leave the application in place that the Chinese developed and build a layer in between the Linux file system and the firmware. This layer is dynamically rewriting the G-Code files as they are read by the application. I have created a block diagram which I will tidy up and share later. And yes, it works. I have tried it out and it works really nicely.
Essentially all it does is take the original G-Code file and parse it. Then it replaces G-Codes unknown to the chinese application with macros that consist of G-Codes that the chinese application understands. All on the fly. It can also do the different feed rate modes and other corrections, fix invalid comments, do scalings, offsets and just about any change to the code right on the controller, before it is loaded by the firmware. Crazy, isn't it
I am also able to intercept actions made in the file manager. E.g. pressing MODE on a file can now not only delete it, but can trigger some other action instead of the deletion (e.g. reboot the controller, rewrite the file with the builtin parser without running it directly, run a shell script...). Same goes for the copy action which could now also trigger additional features. I have also cleaned up the file manager in general and made the names more clear. There are now two folders in the top menu only: USB and a secondary folder which gives access to a new partition in the internal storage of the controller which allows you to store your code there permanently (you can delete it though) without the USB present and a temporary folder in RAM for storing files that will be deleted again when the controller reboots.