Endstops behaviour about g2 HOT 9 CLOSED

from g2.

Hallo I managed to fix it with the $st setting as found in https://github.com/synthetos/TinyG/wiki/TinyG-Configuration-for-Firmware-Version-0.98#digital-input-settings .
Also I have found out that I am in the wrong issue queue ;) - sorry for that, I am actually using Tinyg 0.98 which, from what I have understood, includes some feature and settings from G2.
G2 does not work in neither in Chilipeppr nor CNCJS, the 2 software I am using. I admit I am a bit confused about 0.97 - 0.98 then G2, isn 't G2 compatible with the same software? Which CNC controller should I use with G2 ?

from g2.

What's the physical controller hardware you're using? 😄

from g2.

As mentioned in the OP I am using a Arduino Due and discrete stepper controller, iirc DM420 with 8x microstepping. The machine is custom made.

from g2.

It is common for Dues to run g2core instead of the much older TinyG. g2core is an evolution of TinyG and TinyG is not actively developed, as far as I know. The TinyG and g2core protocols are very similar but g2core has some new features. The cncjs tinyg support code knows about the g2core extensions. I ran a Due/g2core setup on my Taig mill, using cncjs as the sender, for several years.

from g2.

I am veering a bit offtopic now but I tried to load, for example, g2core-Othermill-g2v9k-101.03.bin firmware but when connected to CNCJS I cannot send any command nor the motors activate, what I get from the console is
Connected to COM23 with a baud rate of 115200

feeder> {ej:1}
feeder> {jv:4}
feeder> {qv:1}
feeder> {sv:1}
feeder> {si:100}
feeder> {spe:n}
feeder> {spd:n}
feeder> {spc:n}
feeder> {sps:n}
feeder> {com:n}
feeder> {cof:n}
feeder> {sr:{stat:t,line:t,vel:t,feed:t,unit:t,coor:t,momo:t,plan:t,path:t,dist:t,admo:t,frmo:t,tool:t,posx:t,posy:t,posz:t,posa:t,posb:t,posc:t,mpox:t,mpoy:t,mpoz:t,mpoa:t,mpob:t,mpoc:t,spe:t,spd:t,spc:t,sps:t,com:t,cof:t}}
feeder> {sys:n}
feeder> {mt:n}
feeder> {pwr:n}
feeder> {qr:n}
feeder> {sr:n}

I feel like I am missing something here...

from g2.

I think I might know what is happening. The line

{sr:{stat:t,line:t,vel:t,feed:t,unit:t,coor:t,momo:t,plan:t,path:t,dist:t,admo:t,frmo:t,tool:t,posx:t,posy:t,posz:t,posa:t,posb:t,posc:t,mpox:t,mpoy:t,mpoz:t,mpoa:t,mpob:t,mpoc:t,spe:t,spd:t,spc:t,sps:t,com:t,cof:t}}

is so long that it overflows the serial buffer in g2core and part of the line is lost. When g2core sees the malformed line it gets confused and does not reply properly. Once that happens, the rest of the startup sequence is compromised.

I had that problem once or twice. My memory is hazy but I might have modified cncjs to send a shorter sr line that does not ask for as many report fields.

I do remember that I engaged with the g2core developers to suggest that it would be nice to allow additive status report requests, in that you could list a few fields in one sr line, then a few more in another line, and so on. The way it currently works is that when g2core sees an sr line, it clears the list of status report fields then adds in the ones on that line. The discussion about solving this problem never got resolved.

I have since stopped using g2core in favor of being a primary developer on FluidNC. g2core is nice software, but the developers seem to be focused on commercial users instead of DIY/hobbyist users. (I don't blame them for that; supporting DIYers can be extremely frustrating and a good way to spend lots of time without getting anything in return.)

from g2.

The default branch in g2core is edge-preview. This issue has been fixed. The buffer size now is up to 2k bytes per line.

from g2.

Cool!

from g2.