DDCSV1.1 4 Axis controller

[BrokenEye]

I think the home sequence is fixed at X,Y,Z,A, Antonio, not sure if a Macro could be written to do that, I'm still digging around in the code, so I dont know,sorry.

[antonio]

Manu thanks BrokenEye
why my sequenze starting from z?
 

[Benedikt]

Manu thanks BrokenEye
why my sequenze starting from z?
 

I recall reading it will back to a safe height before homing completely, but I may be corrected there.

[antonio]

I've found this on the slib.nc

(G28 X Y Z A)
O9028
#1=#451
#2=#452
#3=#453
#4=#454
IF #450LT0 GOTO1
#5=#488
#6=#489
#7=#490
#8=#491
GOTO2
N1 #5=#1+#488
#6=#2+#489
#7=#3+#490
#8=#4+#491
N2 G90G00X#5Y#6Z#7A#8
IF#455EQ0GOTO3
IF#455EQ1GOTO4
IF#455EQ2GOTO5
IF#455EQ3GOTO6
IF#455EQ4GOTO7
IF#455EQ5GOTO8
IF#455EQ6GOTO9
N3 #9=-#800
#10=-#801
#11=-#802
#12=-#803
GOTO10
N4 #9=-#800-#804
#10=-#801-#805
#11=-#802-#806
#12=-#803-#807
GOTO10
N5 #9=-#800-#808
#10=-#801-#809
#11=-#802-#810
#12=-#803-#811
GOTO10
N6 #9=-#800-#812
#10=-#801-#813
#11=-#802-#814
#12=-#803-#815
GOTO10
N7 #9=-#800-#816
#10=-#801-#817
#11=-#802-#818
#12=-#803-#819
GOTO10
N8 #9=-#800-#820
#10=-#801-#821
#11=-#802-#822
#12=-#803-#823
GOTO10
N9 #9=-#800-#824
#10=-#801-#825
#11=-#802-#826
#12=-#803-#827
N10 G90G00X#9Y#10Z#11A#12
M99

??

[johnsattuk]

Manu thanks BrokenEye
why my sequenze starting from z?
 

Common practice to take Z out of harms way first

[Benedikt]

I've found this on the slib.nc

(G28 X Y Z A)
O9028
#1=#451
#2=#452
#3=#453
#4=#454
IF #450LT0 GOTO1
#5=#488
#6=#489
#7=#490
#8=#491
GOTO2
N1 #5=#1+#488
#6=#2+#489
#7=#3+#490
#8=#4+#491
N2 G90G00X#5Y#6Z#7A#8
IF#455EQ0GOTO3
IF#455EQ1GOTO4
IF#455EQ2GOTO5
IF#455EQ3GOTO6
IF#455EQ4GOTO7
IF#455EQ5GOTO8
IF#455EQ6GOTO9
N3 #9=-#800
#10=-#801
#11=-#802
#12=-#803
GOTO10
N4 #9=-#800-#804
#10=-#801-#805
#11=-#802-#806
#12=-#803-#807
GOTO10
N5 #9=-#800-#808
#10=-#801-#809
#11=-#802-#810
#12=-#803-#811
GOTO10
N6 #9=-#800-#812
#10=-#801-#813
#11=-#802-#814
#12=-#803-#815
GOTO10
N7 #9=-#800-#816
#10=-#801-#817
#11=-#802-#818
#12=-#803-#819
GOTO10
N8 #9=-#800-#820
#10=-#801-#821
#11=-#802-#822
#12=-#803-#823
GOTO10
N9 #9=-#800-#824
#10=-#801-#825
#11=-#802-#826
#12=-#803-#827
N10 G90G00X#9Y#10Z#11A#12
M99

??

Yes, the original firmware has limited scripting capabilities. There are even more hooks you can create. One is called T.nc. Also, you can try placing files called 1.nc to 9.nc on your USB stick. I have not yet tried any of these or found out what they do, but the disassembly shows that these strings are used in the program.

[Benedikt]

 
Okay, I have thought a bit over the entire project.
I can't free enough time to actually completely rewrite the entire software alone and reverse engineer the driver interface. Maybe sometime, but not now. So I will now focus on improving the original software even further than already using external utility programs. Yes this is absolutely possible. The first point of attack is writing a parser hook that will preparse your G-Code and allow adding new commands. E.g. we can add new cycles that will be expanded by a deamon program that I will write that will always run in the background. Using the bare minimum set of G-Code of the original this will work quite well. We can even fix bugs in the old G-Code processing.
I have also thought of how to implement these new commands into the original firmware and I will be using the file manager. Deleting certain virtual files will now trigger commands and copying files to special virtual directories will automatically parse and process the files for you. I think this is fine for now.

I suggest we should now all post suggestions of what cycles and additions and fixes to the included G-Code parser should be done. Best would be actual examples of what the result should be.
I will also add Lua scripting capabilities to the next version of the firmware (so Lua can be used to extend the G-Code set).

EDIT:
I wanted to add that you cannot brick/permanently break the controller in any way.
Deleting linuxrc is fine too. It will be regenerated on the next boot when the Linux image is copied into RAM. Deleting any other file is also no problem. Installing the 2017 firmware update I released a couple of days ago will fix everything and restore the controller back to normal.

[BrokenEye]

You have done more than enough already Benedikt, so I for one am not expecting you to put your stuff on the back burner, I think we all appreciate the work you have already done, Thank you..

[antonio]

Many many thanks Benedikt!!!


Inviato dal mio iPhone utilizzando Tapatalk

[jjae6]

This is my second post. I do not have this driver yet, but I follow the great advances of this forum and DDCSV1.1 with great enthusiasm.

First I want to congratulate Benedikt for his great work.

Second, Now, I'm looking at the file "slib.nc", and I see the following things (please correct me if I am wrong):

(G28 X Y Z A) >>>>> commentary
O9028    >>>>>>>  G28 command  "Return to Reference Point" with "090" and "28"
#1=#451  >>>>>>  Defines a variable, named "# 1" with a "#451" value.
#2=#452  >>>>>>  Same a "#2" whith "#452" value...
I assume for  "# 451...#452...."  values , the program will read it from somewhere.., maybe some values defined by the user...., or variables as current position values of  XYZA axes, speed values, etc, etc.
......
IF #450LT0 GOTO1 >>> IF "#450@ value "is less than" "0" goto  "1" tag
>>>>>Here is a list of a Comparison Operators for "IF":    EQ: Equal ,     NE: Not equal  ,   GT: Greater than    , GE: Greater than or equal  ,    LT: Less than,     LE: Less than or equal
>>>> and  "goto 1"  tag is  the line 1 defined by "N1...." line
....
GOTO2  >> Jumps to tag "2", defined with a "N2.... " line
.....
 Then, If you look at it, in summary,  the G28 movement is defined by the following TAG lines "N2" and "N10", depending on  "GOTO ..." jumps, and the "IF ..." code according to last modified values "# .."
If code jumps to N2  tag  execute "N2 G90G00X#5Y#6Z#7A#8"  ,  And If the code jumps finally to  N10 tag  execute "N10 G90G00X#9Y#10Z#11A#12" . In both cases, it makes "G90" absolute movement , and then "G0" rapid movement, followed by axes movement with their values,  in case of N2 tag:  X#5  Y#6  Z#7  A#8 .... i.e. X with "#5" last  value, Y with "#6" last value...etc,etc., and same in N10 tag...

In short, inside the code I see that you can modify commands as we want, but we need to know all of defined system variables "#..."  for programming.
For example, In theory, Antonio, you can modify the code to go  Z axis wherever you want  ( i.e. Z00 , select N2 line or/and N10 line)
N10 G90G00Z00
G00X#9Y#10A#12
...
Of course, you should take all necessary precautions with these modifications! but in theory,  ( Remember that I do not have this controller yet ...),  you could change the code for i.e. add a tool change command, or add another XX command with "O90XX" .


PS: Excuse my bad english

[antonio]

Many many thanks jjae6.
I don't have experiance with linux but only some conventionally and basic command/language as my previous school sutyed. In any case I understood what you meen.. is very clear.
I will study better your comment.
Also sorry for my english too.
I would like to know if it possible to modify direct the slib.nc and put on my device without any damage on the firmware and just in case (if it not work) replace the original in any time.
Many thanks again

[Benedikt]

Thanks!
I have mostly completed my modifications of the binary now and it works. I have gained control over the file manager and have simplified it. It is now also possible to detect if certain files are deleted or copied. I will use the copy function to rewrite gcode files. When you copy a file to its origin directory, it will be processed and the preprocessor that I am working on will rewrite the file.
Also thanks jjae6 for your input. If you need a list of all controller settings including their descriptions, head over to http://bmuessig.eu/tools/pandora-configurator or take the machine readable version from http://bmuessig.eu/tools/pandora-configurator/lang_eng.json
These are the values from the script that are prefixed with a #

[maxx2000]

Hello friends. I would like to see the support of the G93 G94 in the controller, this allows using 5 axial cycles for 4 axial machining with a fixed 5 axis.

[Benedikt]

Hello friends. I would like to see the support of the G93 G94 in the controller, this allows using 5 axial cycles for 4 axial machining with a fixed 5 axis.

Hello maxx2000!

Are you talking about the following commands?
G93: Feed Rate Mode (Inverse Time Mode)
G94: Feed Rate Mode (Units per Minute)

Regards,
Benedikt

[maxx2000]

Are you talking about the following commands?
G93: Feed Rate Mode (Inverse Time Mode)
G94: Feed Rate Mode (Units per Minute)

Yes

[Benedikt]

Are you talking about the following commands?
G93: Feed Rate Mode (Inverse Time Mode)
G94: Feed Rate Mode (Units per Minute)

Yes

I think this might be possible.
In inverse time mode, the preprocessor would just calculate the standard length/time feedrate from the time F parameter. Does this sound plausible? Or am I getting something mixed up?
I have never worked with these modes so far.

EDIT: I would like to start making a list of additional G and M commands we need.
Would anyone who has a suggestion please leave a comment with the G-Code number and maybe a quick description?

Thanks,
Benedikt

[maxx2000]

In inverse time mode, the preprocessor would just calculate the standard length/time feedrate from the time F parameter. Does this sound plausible? Or am I getting something mixed up?
I have never worked with these modes so far.

Yes. In the inverse time mode, F means that the movement must be completed in [unit divided by the number of F] minutes. For example, if the number is F = 2.0, the movement should be completed in half a minute.
Example program in an attachment


G94 - Starting the minute feed.  Enabled by default.

Also not bad to add G95 -  In unit mode, per revolution F in the line means the number of inches / millimeters / degrees per minute, depending on the units of length used, which should pass the control point per revolution of the spindle, depending on the units of length used

 and G96 - constant cutting speed.
Note that the number following address S is equal to the cutting speed in meters per minute. The spindle speed is automatically adjusted to maintain the programmed cutting speed.

P.S. I think it is necessary to set the minimum goal of full compatibility of DDCSV with the MACH3 or LinuxCNC program.
I probably want too much from this controller 

[maxx2000]

Code: [Select]


MOTIONRAPID         : G00
MOTIONLINEAR        : G01
MOTIONCW            : G02
MOTIONCCW           : G03
XYPLANE             : G17
ZXPLANE             : G18
YZPLANE             : G19
INCH                : G20
METRIC              : G21
COMPENSATIONOFF     : G40
COMPENSATIONLEFT    : G41
COMPENSATIONRIGHT   : G42
COMPENSATIONPLUS    : G43
COMPENSATIONMINUS   : G44
LENGTHCANCEL        : G49
WORKSYSTEM1         : G54
WORKSYSTEM2         : G55
WORKSYSTEM3         : G56
WORKSYSTEM4         : G57
WORKSYSTEM5         : G58
WORKSYSTEM6         : G59
CANCEL              : G80
DRILL1              : G81
DRILL2              : G82
PECK1               : G83
PECK2               : G73
TAP1                : G84
BORE1               : G85
BORE2               : G86
CANCEL              : G80
ABSOLUTE            : G90
INCREMENTAL         : G91
SETORIGIN           : G92

## added by Udo because of problems with rotary axis speed for 5 axis sim
## ----------------------------------------------------------------------------
MISCSYMBOLICCODE1   : G93     ## INVERSE TIME FEED MODE ON
MISCSYMBOLICCODE2   : G94     ## INVERSE TIME FEED MODE OFF/FEED PER MINUTE ON
## ----------------------------------------------------------------------------

IRETURN             : G98
RRETURN             : G99
ZERORETURN          : G28 G30

PROGRAMSTOP         : M00
OPTIONALSTOP        : M01
SPINDLECW           : M03
SPINDLECCW          : M04
SPINDLEOFF          : M05
TOOLCHANGE          : M06
COOLANTSPFLOOD      : M07
COOLANTON           : M08
COOLANTOFF          : M09
ENDPROGRAM          : M30
WIREON              : M97I think this list will satisfy anyone by 100%

[Benedikt]

I think this list will satisfy anyone by 100%

Thanks!

I think I have heard there are accuracy problems in inch mode. Is this true?
I have only used metric so far. But for milling PCBs inches would be useful.

Rather hoping it might lead to further developing the DDCSV to add in a few missing 'simple' commands...

Would you mind telling me what you would like to see implemented?
Now I am far enough to implement basically any additional processing and add additional G-Code commands.

[maxx2000]

Thanks!

I think I have heard there are accuracy problems in inch mode. Is this true?
I have only used metric so far. But for milling PCBs inches would be useful.

Benedik I also use only the metric, this is the Russian standard.
Most likely this is due to the fact that the ball screw has a metric pitch, and 1 inch = 25.4 mm, it is also difficult to recalculate the motor steps in / turn. If we move from the control of the engines according to Step \ Dir to the analog I think everything will be fine and with inches.

Best regards Maxim

[Simon0362]

Rather hoping it might lead to further developing the DDCSV to add in a few missing 'simple' commands...

Would you mind telling me what you would like to see implemented?
Now I am far enough to implement basically any additional processing and add additional G-Code commands.

Hi Benedikt,
My prime requirement is to support tool changes (and yes, I know those are 'T' and not 'G' code.... ;-) ).
Since there appears to be comprehensive tool table support already contained within the existing code, I need support for a toolchange:
a) pause program at a toolchange Txx command
b) option to stop spindle
c)option to move to defined toolchange position
d) defined restart method - I assume that this would be the start button, similar to a standard 'pause' command

What is also useful is to be able to revise the Z position of the tool at this point as well in case it is not in the tool table or the length is no longer accurate. This is the method I used to use with Mach3 (at toolchange pause, physically move the head up, change the tool, move head back roughly down and then manually re-zero the tool prior to restarting the program) which is good for one-off exercises or with undefined tools.

I use a manual method for toolchanges (in Mach3 I had the 'pause on tool change' set) so if the program can stop and allow me to manually do a change, this will mean I can do complete programs, rather than one for each tool. My future plans include an automatic toolchanger and this would require:
definition of a tool change request line, a response input to say the ATC is ready or busy changing, 3-4 outputs to define the tool number in binary (or could be a single line with the tool number encoded in serial form).

This ATC part comes under the 'would be nice' heading whereas I see the basic toolchanging as essential.

canned cycles for drilling - G73 for shallow holes (interesting, not essential but speeds up drilling)

canned cycle for thread milling int/ext - comes under the 'would be nice' heading

On the subject of the UI - the mock-up looked good but I personally like to see the feed rate displayed - I find this is both a confirmation that it is doing what I thought it should be doing ( :-) ) as well as an easy way to determine where feed rates can be adjusted when moving from prototype to final version- if relevant

Thanks for all of your work so far - deeply appreciated.
Simon

[chriscnc]

@ Simon the Tool change is key for me tool, we need to more just figure it out as I've seen videos of this controller running a ATC, it has the I/O and tool offsets for it and its been done we just need to know the way to configure it with G command savable settings. There is a setting in the pram for enabling some G and M functions..

[chriscnc]

As can be seen in this pic

[ugv]

j'utilise l'appel de sous programme M98P111 (outil1) M98P2(outil222)... les sous programmes sont dans le dossier "slib" et les cordonnés en G53.

[Simon0362]

ugv,
Merci bien, je n'avais aucune idée que les deux instructions a existé...Avez-vous quelques documentation ou des exemples de votre usage? Aussi, pour moi, il est impérative que le program arrête pour le changement manuelle d'être effectué - c'est aussi possible avec les sous programmes?
Cdlt

Does anyone else use these sub programmes for tool changing and is there already a method for pausing the program whilst a manual toolchange is made?

BR
Simon