DDCSV1.1 4 Axis controller

[chriscnc]

Thank you UGV for your reply,  You CNC machine is beautiful. Are you manually adding the M98 to your G code, or is the controller set up to see the M6 T command and refer it to the M98 sub? Also i see you added a slide for your ATC with 2 relays also controlled via the I/O..

Thank you for your time and info

[chriscnc]

Ok Simon I think i understand what UGV is doing after a little digging

So M98 will invoke the controller to run a referenced sub routine. The sub routine is just standard G code and then is using M99 command to end the sub routine. So to stop your spindle and pause for a tool change your sub routine would be:

 G53 to refer back to machine coordinates
 G01 Z to a safe height
 M5 to stop the spindle
 G01 XYZ to your tool change position
 G0 for a Pause and Cycle start
 M3 to turn the spindle back on
 T# G49 to reference the tool length offset from the saved table
 G54 to ref back to work concordance
 M99 to terminate the sub routine.

Here is what i need to understand, Mach can be told to run a VB script or M98 when it sees a M6 or ignore it, can this controller be told to run a M98 when it sees a M6 or do we need to swap out M6 commands in our code for m98.. some CAM postprocessors can be made to do this automatically, But a controller ref M6 to m98 XXXX would be awesome. Also, can the M98 be stored on the controller or needs to be added to the end of the Gcode for M98 reference. There are G and M codes for driving outputs high and low, pauses etc so a full ATC such as UGV is posable as a sub

[Benedikt]

Ok Simon I think i understand what UGV is doing after a little digging

So M98 will invoke the controller to run a referenced sub routine. The sub routine is just standard G code and then is using M99 command to end the sub routine. So to stop your spindle and pause for a tool change your sub routine would be:

 G53 to refer back to machine coordinates
 G01 Z to a safe height
 M5 to stop the spindle
 G01 XYZ to your tool change position
 G0 for a Pause and Cycle start
 M3 to turn the spindle back on
 T# G49 to reference the tool length offset from the saved table
 G54 to ref back to work concordance
 M99 to terminate the sub routine.

Here is what i need to understand, Mach can be told to run a VB script or M98 when it sees a M6 or ignore it, can this controller be told to run a M98 when it sees a M6 or do we need to swap out M6 commands in our code for m98.. some CAM postprocessors can be made to do this automatically, But a controller ref M6 to m98 XXXX would be awesome. Also, can the M98 be stored on the controller or needs to be added to the end of the Gcode for M98 reference. There are G and M codes for driving outputs high and low, pauses etc so a full ATC such as UGV is posable as a sub

The current version of the Pandora firmware I am working on will support on the fly postprocessing right on the controller. I was asking you all to tell me what it needs to rewrite and do to the code. It can easily replace G-codes by macros, do conditional processing, fix issues, improve accuracy, calculate tool compensation, fix inches by converting it to metric values, and so on. Feel free to suggest anything 

[chriscnc]

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

http://www.hindtechnology.com/

[John Stevenson]

Problem with the HIND is it still uses everything BUT a PC and that's what we are trying to get away from, clunky monitors, keyboards and mouse.

[John Stevenson]

One thing lacking on this controller and not available unless you spend 3x the price is support for lathes.

Not a lot of different between lathe and mill until you get to threading and then you need three additional physical inputs. A+, B+ and Z+ or index.
Just an indexing pulse like Mach 3 uses will not work.

Now I don't know if any inputs can be freed up by daisy chaining limits or such like but I have a feeling it's a bridge too far ?

[Benedikt]

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

http://www.hindtechnology.com/

Hi Chris!
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.

[chriscnc]

@ John... Yep i don't like the HIND its basically a DDCSV but with external monitor and keyboard. Im just referring to its UI and options as its all based on a single ARM chip, The DDCSV is using a ARM for the front end and a FPGA for motion... I.E if we can get this to match the Hind UI we all will have a much better controller for the cheaps.

[Benedikt]

Here is a quick screenshot of the new file manager:

[chriscnc]

Got ya ok i see what your going for.... Where can i help. I can start making a list of what the controller cant do/has issues with. I'm trying to also identify options and what it can do as there seams to be some hidden features, so it may be helpful with integration with pandora i.e we may just need to reference an internal M command that is already there. Is there any latency or processing issues running this app in parallel.

[chriscnc]

Benedikt, can the USB port support a HAL/HID keyboard with Pandora? If so i can program a Teensy for a custom layout mini panel keyboard with screen ref buttons and feed/ spindle override knobs. Pandora would just need to be able to map a keyboard input to functions. This way we have quick access to functions.

[Benedikt]

Got ya ok i see what your going for.... Where can i help. I can start making a list of what the controller cant do/has issues with. I'm trying to also identify options and what it can do as there seams to be some hidden features, so it may be helpful with integration with pandora i.e we may just need to reference an internal M command that is already there. Is there any latency or processing issues running this app in parallel.

Benedikt, can the USB port support a HAL/HID keyboard with Pandora? If so i can program a Teensy for a custom layout mini panel keyboard with screen ref buttons and feed/ spindle override knobs. Pandora would just need to be able to map a keyboard input to functions. This way we have quick access to functions.

That would be great. A list of what needs to be changed and one of the hidden features is always useful!
Parallel processing should work fine. The controller can easily do that at the same time.
Also yes USB HID is fully supported. However there is no actual linux driver for the keypad. The keypad seems to be directly controlled via I2C. I will see what I can do ;)

[Simon0362]

Ok Simon I think i understand what UGV is doing after a little digging

So M98 will invoke the controller to run a referenced sub routine. The sub routine is just standard G code and then is using M99 command to end the sub routine. So to stop your spindle and pause for a tool change your sub routine would be:

 G53 to refer back to machine coordinates
 G01 Z to a safe height
 M5 to stop the spindle
 G01 XYZ to your tool change position
 G0 for a Pause and Cycle start
 M3 to turn the spindle back on
 T# G49 to reference the tool length offset from the saved table
 G54 to ref back to work concordance
 M99 to terminate the sub routine.

Here is what i need to understand, Mach can be told to run a VB script or M98 when it sees a M6 or ignore it, can this controller be told to run a M98 when it sees a M6 or do we need to swap out M6 commands in our code for m98.. some CAM postprocessors can be made to do this automatically, But a controller ref M6 to m98 XXXX would be awesome. Also, can the M98 be stored on the controller or needs to be added to the end of the Gcode for M98 reference. There are G and M codes for driving outputs high and low, pauses etc so a full ATC such as UGV is posable as a sub

Chris,
Thanks for the input - since I use a 'manual' toolchange, I need a program stop whilst I go through the undo-replace-tighten routine and I can't see how that will happen with a G0 - or am I just being dim this morning?
The rest of it is very clear and when I get 5 spare moments, I will investigate further...
BR
Simon

[librarymark]

Folks - I am a machinist hobbyist from Michigan, USA, and have been watching this thread with great interest. The work on reverse engineering this little thing has been nothing short of amazing!

I am building a  2'x4' cnc router and would like to try a DDSCV1 on it, but I have a question that I am hoping you can answer. It will have two steppers on the long axis. Can this unit drive them from separate outputs, or do I have to tie them together on one output? This is easy to do with linuxcnc; how is it done with the DDSCV1?

And to the gentleman who wrote the Pandora configurator PHP script: Part of my day job is web interface design. May I have a copy of your scripts so that I may tinker with it? I like what you have done, but I think we can spiff up the page with some tabs and such, and maybe a guided wizard.

Thanks!

Mark in Dowling, MI

[maxx2000]

I am building a  2'x4' cnc router and would like to try a DDSCV1 on it, but I have a question that I am hoping you can answer. It will have two steppers on the long axis. Can this unit drive them from separate outputs, or do I have to tie them together on one output? This is easy to do with linuxcnc; how is it done with the DDSCV1?

I correctly understood you, 2 motors on one axis? DDCSV does not allow you to configure the subordinate axis as in the Linux CNC or MACH3

[Benedikt]

Folks - I am a machinist hobbyist from Michigan, USA, and have been watching this thread with great interest. The work on reverse engineering this little thing has been nothing short of amazing!

I am building a  2'x4' cnc router and would like to try a DDSCV1 on it, but I have a question that I am hoping you can answer. It will have two steppers on the long axis. Can this unit drive them from separate outputs, or do I have to tie them together on one output? This is easy to do with linuxcnc; how is it done with the DDSCV1?

And to the gentleman who wrote the Pandora configurator PHP script: Part of my day job is web interface design. May I have a copy of your scripts so that I may tinker with it? I like what you have done, but I think we can spiff up the page with some tabs and such, and maybe a guided wizard.

Thanks!

Mark in Dowling, MI

Welcome, librarymark!

Thanks for the kind words, glad you liked it!
I infrequently design websites for other people on request too. I was quite busy and had no time for the design. It really is a pain to use and honestly does not look too visually appealing as it is right now.
I would be glad if you would give this a shot! Especially a wizard would be great. I would also need a tiny admin page, where I can trigger the scripts to re-read the original firmware files to convert them to json files. Currently this is done by passing special GET and POST parameters to the front- and backend.
I will send you the code, however it is currently quite unpolished and should really be reworked. Tell me, how you prefer to handle the front-end and I will greatly improve the back-end.

[ugv]

M0 pour faire pause et start pour reprendre

[jjae6]

I found the firmware for RMHV2.1 (ddcsv from ratt motor), Inside this zip file are some texts translated into English. ( inside all of *.nc files ).

There are really valuable comments as i.e

"(Reads the current machine tool coordinate position ?ÁÈ?µ?Ç?µ??ß?úе?ø?êÎ?ÖÃ)
#20=#864
#21=#865
#22=#866
;Determines whether the system uses the fixed position tool presetting mode or the current position setting mode
(?Ì???Ôµ?Ä?Ê?ÏÂ??Çó?öX??Y??ZµÄ?ø?øÁ?)
IF#571EQ0GOTO1
#1=#572-#20
#2=#573-#21
#3=#574-#22
....."

Maybe can serve to understand all of variables list

[librarymark]

I am building a  2'x4' cnc router and would like to try a DDSCV1 on it, but I have a question that I am hoping you can answer. It will have two steppers on the long axis. Can this unit drive them from separate outputs, or do I have to tie them together on one output? This is easy to do with linuxcnc; how is it done with the DDSCV1?

I correctly understood you, 2 motors on one axis? DDCSV does not allow you to configure the subordinate axis as in the Linux CNC or MACH3

Yup - two motors on one axis. That's too bad. So I would have to do some sort of pairing after the controller. That would be a nice feature to add.

[Benedikt]

I am building a  2'x4' cnc router and would like to try a DDSCV1 on it, but I have a question that I am hoping you can answer. It will have two steppers on the long axis. Can this unit drive them from separate outputs, or do I have to tie them together on one output? This is easy to do with linuxcnc; how is it done with the DDSCV1?

I correctly understood you, 2 motors on one axis? DDCSV does not allow you to configure the subordinate axis as in the Linux CNC or MACH3

Yup - two motors on one axis. That's too bad. So I would have to do some sort of pairing after the controller. That would be a nice feature to add.

There is just not enough I/O. I am simply tieing the signals of my axis together.

[awemawson]

Are there enough outputs that you could clock values into an external register set to expand the outputs? (This was pretty well standard practise in the early days when the number of pins on a chip were the limiting factor)

[librarymark]

it's got 4 axis' worth of IO - seems to me that you could hook up 4 stepper drivers and slave two of them in software, but I don't even have one of these yet, so I don't know squat.

[Joules]

The X output is quite capable of running two stepper controllers.  My old router had 2 X-axis motors each with its own driver module driven from the X-axis signals.

[librarymark]

The X output is quite capable of running two stepper controllers.  My old router had 2 X-axis motors each with its own driver module driven from the X-axis signals.

OK - I will try that - thanks!

[Benedikt]

The X output is quite capable of running two stepper controllers.  My old router had 2 X-axis motors each with its own driver module driven from the X-axis signals.

This is essentially how I am driving my Y axis and I had no issues so far.

it's got 4 axis' worth of IO - seems to me that you could hook up 4 stepper drivers and slave two of them in software, but I don't even have one of these yet, so I don't know squat.

While this sounds nice, bear in mind the FPGA is handling a lot of the actual drive work. That said, it's most likely just writing a number of steps to go for each axis into an FPGA register. Controlling any of the axis ports in an arbitrary way (using them as IO) is not possible.
However, there is a serial port on the outside. Does anyone know what it does?
What I would want to do is write a driver similar to the motiondev.ko driver that sits in between the application and the actual driver and just records what is sent and might also be able to write data into the stream. I will eventually research this further.
This might make reverse-engineering the firmware itself a lot easier, since it opens up some debug capabilities.