DDCSV1.1 4 Axis controller

[chriscnc]

@Will D

The new code was made just for this, I have different steps per mm and all 3 axes. so with the new code, you must turn on software interpolation line #113 if i rember and set the res to .001  If your axis are the same then you can leave #113 off but there is still some CV benefits.

[Will_D]

Thanks for the info Chris.

To be sure to be sure at the moment I am running version 2017-04-16-IM NOR (the highly recomended version!)

I did what I asked about re the X and y steps per mm and set them both to 400 and tweaked the drivers micro-steps accordingly.

Result: Circles that are circular! Happy Days

When you talk about line #113 do you mean a parameter of that number? My config data file does not have a #113 parameter

[dale brisson]

i dont have limits stops yet so how do you jog the the ddcsv1.1 to where ever you want on the table and manually zero the axis? when im testing x moves back to zero and i want to zero it where it is 


ok i think i got it 2nd y twice
so now there coordinates  beside the left side how do you get rid of it or to reset it

[Will_D]

Getting into Fusion 360 to produce the code for this controller.

Question is which post processor are people using?

There are lots to choose from ion F-360.

Also does this version support subroutine calls?

[merc]

Merc and Kevn,

You have your G code set for 3 axis arc interpolation. look at your Gcode see the Z move on a G03 line. This controller only supports interpolated arc move on a single plane at a time ( this is pretty common). most controllers till the very late 90's started to offer interpolate arcs on 3 axis. This is a setting in your post processor to restrict arcs to a single plane like x/y per line. Don't be mistaken, this controller can make perfect 3 axis helix moves. Its just the way the post processor handles the code by mixing G01 with G03 moves, the motion of the machine is no different and super smooth as the controller can prosses code with lookahead very fast. Just select no helix moves in your post processor, it will still helix, just won't use a G03 with a Z on the same line. Long story short, Gcode is correct for a different controller, that's why it will work in simulators and some other controllers. you simply have the wrong post processor for this controller. look at the postprocessor file and look for helix allowed and or arc interpolation planes allowed making sure its set to 1.  Look at the screenshot of the fusion 360 post.

Hello! The problem is not about helixes, but about arc. Here is the video and gcode without 3d helixes but with invalid behaviour.
DDCSV adds circle instead of the arc in the bottom left corner. Here is the GCODE and video. Same code tested on another CNC with different controller and it works ok.

Video link: https://www.youtube.com/watch?v=GcBHee5kgoA
GCODE: https://gist.github.com/arrowcircle/fe0522a7553b352d7c36e412a3eeeca6

Problem is on lines N290 and N460.

Any ideas how to fix this flaw?

[old Zozo]

DDCSV adds circle instead of the arc in the bottom left corner.

Any ideas how to fix this flaw?

I have had same problem, when value of pulse/mm was under 250. (for  X and Y axis)
I've  increased it to  500 pulse/mm, and now controller works  well.
I use linuxcnc or emc2 postprocessor for G-codes.

[blades]

DDCSV adds circle instead of the arc in the bottom left corner.

Any ideas how to fix this flaw?

I have had same problem, when value of pulse/mm was under 250. (for  X and Y axis)
I've  increased it to  500 pulse/mm, and now controller works  well.
I use linuxcnc or emc2 postprocessor for G-codes.

How can you change your pulse/mm setting? Did you double a pulley size or gear ratio or something?
I know that setting no's. 33 (motor start speed) and 416 (time between DIR and pulse) can have quite an effect when pulse settings are outside the normal range. My Z axis was the issue because I had it set to 12000 steps/in (yes, I use inches). It was so high because of using a Gecko G540 that has 10x dedicated microstepping that can't be changed. I set my #33 to 20, and #416 to 200. I don't fully understand these settings, but thanks to member PPRINT (Rob) for pointing this out to me back around post# 635.

[old Zozo]

How can you change your pulse/mm setting? Did you double a pulley size or gear ratio or something?

No, I use not gear ratio, stepper motor drives directly threaded spindle by a clutch.
Motor moves 1.8 degree/step, so the  step/rev=200
Pitch of threaded spindle is 6.35 mm.

This way,  200 step moves to 6.35 mm,  therefore 31.496 step moves one mm. (31.496 pulse/mm )

Now, need to use microsteps, stepper driver knows it.

If the setup:
-half step   31.496 x 2 = 62.992 pulse/mm
-1/4 step    31.496 x 4 = 125.984 pulse/mm
-1/16 step   31.496 x 16 = 503.937 pulse/mm   (I use it )

503.937 pulse/mm x 25,4 =  12800 pulse/inch

[Benedikt]

Good afternoon!

I have been in touch with the original engineer some more and we've got a late christmas present for you.
The update we have been working on is going to be huge and will allow adding custom cycles through plugins in the future, allow more langauges than just English and Chinese, will fix bugs and add more functionality. This update is the first one during this series of updates. It includes our community translations as the new default English translation.
This attached firmware is likely not stable and may not work properly, but testing is very welcome.
I have not been able to test it, since I am not at home, but instead with the family during the holiday season.
You can always roll back to a stable version using PandoraInstaller for installing either the factory version or the modded firmware.
I have attached an update archive to this post. You will need to unzip the contents to the root (uppermost) folder of a FAT32 formatted USB stick and follow the usual instructions.

Best regards and happy holidays,
Benedikt

[Will_D]

Merry Christmas Benedikt.

Wow can't wait to see the new release.

I hope the new manual will list all the G and M codes (and any other) that are supported in this release.

Also a list of what has been fixed (like a release note) As you know i'm into backlash!!

Again many many thanks for all the hard work you and your colleagues have put into this controller.

Will, Dublin.ie

[Benedikt]

Hello,

I have just had a look at the source code and I think I have found the list of supported codes and I will post them here soon.
Apart from that, I have just found the place, where inches are handled:

Code: [Select]

; =============== S U B R O U T I N E =======================================

; Attributes: bp-based frame

ParserGGroup6 ; CODE XREF: FindProgramBlock:loc_43FF4p
; ParserProgramBlock+A54p ...

var_20 = -0x20

MOV R12, SP
STMFD SP!, {R4-R7,R11,R12,LR,PC}
SUB R11, R12, #4
SUB SP, SP, #8
LDR R3, =bakNcBlock
LDR R3, [R3,#(dword_1279BC - 0x1279A4)]
CMP R3, #0x14
BNE loc_3C570
MOV R3, #0
STR R3, [R11,#var_20]
B loc_3C54C
; ---------------------------------------------------------------------------

loc_3C470 ; CODE XREF: ParserGGroup6+110j
LDR R7, [R11,#var_20]
LDR R3, [R11,#var_20]
ADD R3, R3, #0x22
LDR R1, =systemVarTable
MOV R3, R3,LSL#2
MOV R2, R3,LSL#2
ADD R3, R3, R2
MOV R2, R3,LSL#4
ADD R3, R3, R2
ADD R3, R3, R1
LDR R3, [R3]
MOV R0, R3
BL __extendsfdf2
MOV R3, R0
MOV R4, R1
MOV R0, R3
MOV R1, R4
MOV R2, #0
MOV R3, #0x40190000
BL __muldf3
MOV R3, R0
MOV R4, R1
MOV R5, R3
MOV R6, R4
LDR R3, [R11,#var_20]
ADD R3, R3, #0xC
LDR R1, =systemVarTable
MOV R3, R3,LSL#2
MOV R2, R3,LSL#2
ADD R3, R3, R2
MOV R2, R3,LSL#4
ADD R3, R3, R2
ADD R3, R3, R1
LDR R3, [R3]
MOV R0, R3
BL __extendsfdf2
MOV R3, R0
MOV R4, R1
MOV R0, R5
MOV R1, R6
MOV R2, R3
MOV R3, R4
BL __muldf3
MOV R3, R0
MOV R4, R1
MOV R0, R3
MOV R1, R4
BL __truncdfsf2
MOV R2, R0
LDR R3, =perUnitToPulse
STR R2, [R3,R7,LSL#2]
LDR R3, [R11,#var_20]
ADD R3, R3, #1
STR R3, [R11,#var_20]

loc_3C54C ; CODE XREF: ParserGGroup6+28j
LDR R3, [R11,#var_20]
CMP R3, #2
BLE loc_3C470
LDR R2, =systemVarTable
LDR R3, =0x3124
LDR R2, [R2,R3]
LDR R3, =perUnitToPulse
STR R2, [R3,#(dword_127C08 - 0x127BFC)]
B loc_3C614
; ---------------------------------------------------------------------------

loc_3C570 ; CODE XREF: ParserGGroup6+1Cj
MOV R3, #0
STR R3, [R11,#var_20]
B loc_3C5F4
; ---------------------------------------------------------------------------

loc_3C57C ; CODE XREF: ParserGGroup6+1B8j
LDR R4, [R11,#var_20]
LDR R3, [R11,#var_20]
ADD R3, R3, #0x22
LDR R1, =systemVarTable
MOV R3, R3,LSL#2
MOV R2, R3,LSL#2
ADD R3, R3, R2
MOV R2, R3,LSL#4
ADD R3, R3, R2
ADD R3, R3, R1
LDR R0, [R3]
LDR R3, [R11,#var_20]
ADD R3, R3, #0xC
LDR R1, =systemVarTable
MOV R3, R3,LSL#2
MOV R2, R3,LSL#2
ADD R3, R3, R2
MOV R2, R3,LSL#4
ADD R3, R3, R2
ADD R3, R3, R1
LDR R3, [R3]
MOV R1, R3
BL __mulsf3
MOV R3, R0
MOV R2, R3
LDR R3, =perUnitToPulse
STR R2, [R3,R4,LSL#2]
LDR R3, [R11,#var_20]
ADD R3, R3, #1
STR R3, [R11,#var_20]

loc_3C5F4 ; CODE XREF: ParserGGroup6+134j
LDR R3, [R11,#var_20]
CMP R3, #2
BLE loc_3C57C
LDR R2, =systemVarTable
LDR R3, =0x3124
LDR R2, [R2,R3]
LDR R3, =perUnitToPulse
STR R2, [R3,#(dword_127C08 - 0x127BFC)]

loc_3C614 ; CODE XREF: ParserGGroup6+128j
SUB SP, R11, #0x1C
LDMFD SP, {R4-R7,R11,SP,PC}
; End of function ParserGGroup6

; ---------------------------------------------------------------------------
off_3C61C DCD bakNcBlock ; DATA XREF: ParserGGroup6+10r
off_3C620 DCD systemVarTable ; DATA XREF: ParserGGroup6+38r
; ParserGGroup6+98r ...
off_3C624 DCD perUnitToPulse ; DATA XREF: ParserGGroup6+F4r
; ParserGGroup6+120r ...
dword_3C628 DCD 0x3124 ; DATA XREF: ParserGGroup6+118r
; ParserGGroup6+1C0r

TLDR:
This function changes the PulseToUnit once it hits a G20.
It recalculates the PulseToUnit 3 times (for the X, Y and Z axis) and when in inch mode, multiplies it by 2.390625.
The calculation appears to take the steps per mm from the configuration params #34 (X-axis pulses per mm), #35 (Y-axis pulses per mm), #36 (Z-axis pulses per mm) into account when recalculating.
I have just had a brief look over it and I may have overseen something important.
I can easily change this multiplication constant to some other one (2.54 = 0x40228f5c for example), if this will increase the accuracy.

These were G/(M?)-Codes I found by quickly searching through the huge code listing. It may not be correct and is certainly incomplete, but it is a start:

Code: [Select]

0
1

12
13
28
29

17
18
19

20
21

43 ?
44 ?
49 ?

53
54
55
56
57
58
59

90
91

98 ?
99 ?

BR,
Benedikt

[WeldingRod]

Benedikt,
Great work on Pandora!  Thank you so much! 

I've been running the original DDCSV firmware on an engraver for quite a while now and it worked quite well.  I'm now in the process of upping my game to FOUR  axis and an OX from SMW3D (great kit, BTW).  I will post the settings once I have them thrashed out.  FYI, my rotary is a Haas HA5C with a fresh stepper motor (the old slo-syn one was corroded solid with globs of coolant goo and white paste.  Blech.).  Nice unit, BTW.  5 degrees per turn of the stepper.

It looks like I may be the only person using the 4th axis.  My challenge is there doesn't seem to be any way to control the feed rate on the 4th axis, other than doing the FRO and down method to set the overall feed rate to 70 or 80%.  I've tried quite a few gcodes without success.  The following code makes the rotary go back and forth to 30 degrees, but all four cycles are the same speed.  FYI, I tried this code again on Pandora and got the same result.  On the good side, the angular axis DOES work, and is repeatable (once I slow down the master feed enough so it doesn't loose steps).

G1 A30 F100
G1 A0 F100
G1 A30 F10
G1 A0 F10
G1 A30 F1
G1 A0 F1
G1 A30 F0.1

I've also tried pre-setting the feed rate without any change in feed speed:
G1 F10
G1 A30
G1 A0
G1 F1
G1 A30
G1 A0

Any ideas?  All of the maximum speed and acceleration settings seem to be tied to manual mode, except 76, 77, 80, and 99.  However, all of these are linear; the only angular ones are for manual.

[WeldingRod]

I took Benedikt's gcode list (harvested from the firmware) and added "what the heck is that".  I also cross referenced it to the manual.

Gcodes on DDCSV
0   Quick cut
1   Standard cut
   
G2   Clockwise cut                           Not on Benedikt's list
G3   Counterclockwise cut                     Not on Benedikt's list
G4   Dwell (milliseconds?)                     Not on Benedikt's list

12   Clockwise circle w/entrance and exit arcs         Not in manual
13   Counter clockwise circle w/entrance and exit arcs        Not in manual

17   XY plane selection
18   ZX plane selection
19   YZ plane selection
   
20   English units
21   Metric units

28   Return to home                     Not in manual
29   **no clue, used for bed leveling on 3d printers**   Not in manual

43   Tool length compensation (negative)         Not in manual
44    Tool length compensation (positive)         Not in manual
49    Cancel tool length compensation             Not in manual

53   Turn off G54-G59 offset                  Not in manual
54   Select G54 coordinate system
55   Select G55 coordinate system
56   Select G56 coordinate system
57   Select G57 coordinate system
58   Select G58 coordinate system
59   Select G59 coordinate system

G81   Drill hole                     Not on Benedikt's list
G82   Drill hole                     Not on Benedikt's list
G83   Circulation drill hole               Not on Benedikt's list

90   Absolute positioning
91   Increment positioning

98 ?   Back to R point according to "time fixed feed"
99 ?   Fixed circulation W.R.T. G81/82/83

[WeldingRod]

OK, got the OX moving!
Re-testing the rotary axis...  I  was watching the display this time.  There is a line on the display that says F....actual feed rate....feed set point
When I run the pendant on X, y, z, I see the set point at 500 on the right, and I see the feed speed up to 500 and then slow back down, according to the acceleration.  When I run the A axis program above, I see the feed set point change at  each step of the program.  HOWEVER, the actual feed ramps up to about 99 and then back down for ALL the various feed rates.  When I slow down the master feed rate, the A rotation slows down as expected.
on a side note, the maximum A speed seems to have gone down some.  I wish I knew which setting that was!  I have no idea where the 100 limit comes from!

[WeldingRod]

High frustration!  I forgot that the DDCSV has a default minimum steps per MM value of 50.  The Ox has 26.670 steps per mm on X and Y, and 50 on Z.
 
Is there any hope that this value is easy to change in the code?

[Benedikt]

High frustration!  I forgot that the DDCSV has a default minimum steps per MM value of 50.  The Ox has 26.670 steps per mm on X and Y, and 50 on Z.
 
Is there any hope that this value is easy to change in the code?

If the value is not limited by the FPGA, I could patch it theoretically.

I took Benedikt's gcode list (harvested from the firmware) and added "what the heck is that".  I also cross referenced it to the manual.

Gcodes on DDCSV
0   Quick cut
1   Standard cut
   
G2   Clockwise cut                           Not on Benedikt's list
G3   Counterclockwise cut                     Not on Benedikt's list

12   Clockwise circle w/entrance and exit arcs         Not in manual
13   Counter clockwise circle w/entrance and exit arcs        Not in manual

17   XY plane selection
18   ZX plane selection
19   YZ plane selection
   
20   English units
21   Metric units

28   Return to home                     Not in manual
29   **no clue, used for bed leveling on 3d printers**   Not in manual

43   Tool length compensation (negative)         Not in manual
44    Tool length compensation (positive)         Not in manual
49    Cancel tool length compensation             Not in manual

53   Turn off G54-G59 offset                  Not in manual
54   Select G54 coordinate system
55   Select G55 coordinate system
56   Select G56 coordinate system
57   Select G57 coordinate system
58   Select G58 coordinate system
59   Select G59 coordinate system

G81   Drill hole                     Not on Benedikt's list
G82   Drill hole                     Not on Benedikt's list
G83   Circulation drill hole               Not on Benedikt's list

90   Absolute positioning
91   Increment positioning

98 ?   Back to R point according to "time fixed feed"
99 ?   Fixed circulation W.R.T. G81/82/83

Looks good. I would also add G4, which is also part of the set, but not in the manual. I just looked through the numeric compare statements in the parser blocks.
It's all rather cryptic, since I am working with disassembled code that was originally compiled from C/C++ code. There are no comments of course to help understand their logic of doing things, there is no theory of operation nor are there any names for the local variables. Also floating point is all in software, so there is a big overhead there that also complicates reverse-engineering.

[WeldingRod]

 
OK, so I copied out the "eng" file on mine and then edited the range of X and Y to allow down to 20 steps/mm... and it WORKED!!!
My Ox is now running!  It will actually accelerate fast enough that the base slides back and forth on the bench!
I need to wire the limit switches and then I'll publish the parameter set I'm using.

Benedikt, you might want to go ahead and modify the master Pandora file the same way; belt driven/fast machines will need the additional range on steps/mm.  20 steps/mm is probably low enough for almost anything folks will want to build.

[Benedikt]

OK, so I copied out the "eng" file on mine and then edited the range of X and Y to allow down to 20 steps/mm... and it WORKED!!!
My Ox is now running!  It will actually accelerate fast enough that the base slides back and forth on the bench!
I need to wire the limit switches and then I'll publish the parameter set I'm using.

Benedikt, you might want to go ahead and modify the master Pandora file the same way; belt driven/fast machines will need the additional range on steps/mm.  20 steps/mm is probably low enough for almost anything folks will want to build.

Surely, I can lower the minimum value in both the online configuration generator and the firmware if it really works well for you.

[Benedikt]

 
Here's the latest version of Pandora for DDCSV1.1 and RMHV2.1:
http://dl.pandora-cnc.eu/firmware/bleeding/Pandora-20180106.zip

It's not yet tested and therefore I can't claim it is stable. Testing is very welcome.
I have decreased the minimum steps per mm and increased the maximum steps per mm.
Also inch accuracy should be fixed with this version as well. Again, this should be tested.

Best regards,
Benedikt

[DirkC]

Hi Benedikt

This is my first post. I received this week my unit and immediately flashed it with the latest recommended firmware. Everything seems to work. I am still waiting for the other parts to arrive.
When looking at  the configuration I found that the parameter #417 pulse width is missing.
In the original product manual on page 74 screenshot 3.68 it is visible. On the pandora configuration site this parameter is also missing.
I tried to add the parameter manually to the config file and loaded it , but still this parameter doesn’t show up after reboot.
Is this a know issue. This is certainly not urgent.
In a previous 3D printer project I needed to tweak this to get my stepper motors working correctly ( Smoothyboard)
Already a big thank you to give this unit a second youth 

Dirk

[Will_D]

Looking at the code the ParserGGroupnn procedure names are based on the Grouping of gcodes. This was defined by Fanuc a long time ago!

Group 1 are the movement commands G00 .. G3
Group 2 is the Plane selection group G17, 18, 19
Group 3 is the Dimension mode G90, 91
Group 4 is the units group G20, 21

Group 7 is the Cutter Radius Offset group (G40, 41 and 42) and so these may be implemented.
Group 8 is the tool length compensation set (G43, 44, 49) and so may these.

Group 10 is the Return Mode group G98, 99
Group 12 is the coorddinate system G54 ,, 59 and it looks like G53 is oresent (technically in Group 0 the non modal commands)

Will

[Benedikt]

Looking at the code the ParserGGroupnn procedure names are based on the Grouping of gcodes. This was defined by Fanuc a long time ago!

Group 1 are the movement commands G00 .. G3
Group 2 is the Plane selection group G17, 18, 19
Group 3 is the Dimension mode G90, 91
Group 4 is the units group G20, 21

Group 7 is the Cutter Radius Offset group (G40, 41 and 42) and so these may be implemented.
Group 8 is the tool length compensation set (G43, 44, 49) and so may these.

Group 10 is the Return Mode group G98, 99
Group 12 is the coorddinate system G54 ,, 59 and it looks like G53 is oresent (technically in Group 0 the non modal commands)

Will

Thats interesting. I was not aware of that.
Thanks for sharing! 

[WeldingRod]

Progress!    It turns out that the parameter:
5    Min. log. radius in 4-axis mode
Translates to: divide maximum feed rate (and probably acceleration) by 360 * pi* this number to get degrees per minute on the rotary axis.  FYI, I'm guessing on the constants.  What I actually did is test at a log radius of 5mm, 55mm, and 555mm.  5mm was so fast the motor lost steps unless I set FRO down to 20%.  55mm was slow enough that 100% FRO didn't lose steps.  555mm was even slower.

HOWEVER, I'm pretty sure it doesn't pay any attention to the F command WRT the rotary axis, at least alone.  I need to play with some coordinated motions more.

[WeldingRod]

Back to Backlash Basics.

Has anyone used this on the  version 1.1 controller and the 16-04-17 software?

I know I have about 0.1 mm backlash in X and Y

If I run this code

G17 G21 G90 G94 G54
(^Safe Block^)
F 2.
S 10.
G1 X-1.  Y-1.
G1 X0.
Y0.
G1 X10.
Y10.
G1 X0.
Y0.
M30

A quick question on the Gcode above: is the F 2 line the correct syntax?  Or should it be G1 F2, or G1 F 2? 

[lordprimoz]

Hi Guys,

when running gcode on my machine I have this really werid issue where there is a significant deviation in the actual position(as well as the position it shows on the display) and the position it should be according to the gcode.

im trying to mill a vacuumtable, which is basically a milling grid pattern where i step down 0.1mm for each level.
Fusion360 generated the gcode for this project.
 
I noticed that (it seems to be in all axes) the z-axis has this weird difference. for example: the gcode tells the machine it should go to -0.8mm on the Z-axis, but it actually only goes down 0.774mm. After moving up and to a new spot it moves moves down again. This time its also different from the previous value. This might be something i would expect from (failing?)backlash settings, but these are all disabled and set to 0.

So essentially the machine starts and moves to a xy coordinate, then it moves down (gcode Z-0.8) to -0.7xx. When it moves up again to its safe position and comes back down the z-depth is no longer the same as previous, even though this depth was already wrong.

When telling the controller to move to a certain z-heigth from the display itsself it does indeed move to exactly that position....


Anyone got any ideas what is causing this?