BUG: Unable to output negative zero

[ikcalb]

In some CNC controllers (i.e. linuxcnc. see #3 at http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WrappedRotaryAxes ), the sign of the rotary axis position is used to determine the direction of the rotary movement.

I dont't mean to start a discussion whether this is useful (spoiler: IMHO this is CRUCIAL),

BUT:

It should be able, to output a negative zero!

(JavaScript, the lang of the post does distinguish positive or negative zero, so this should be no showstopper)

P.S. Any other controller i know (Heidenhain, Siemens) would ignore the negative sign on zero anyways

[AchimN]

The generic fadal post processor has that logic implemented:

https://cam.autodesk.com/hsmposts?p=fadal

Look for function getABCDir(_a, _b, _c)

[ikcalb]

Excuse me if I'm sounding impolite: Please read my question again, because I don't know how to rephrase it.

I'm not talking about any random angle - just for *0* (read zero) degrees.

I've seen that logic (cleaned up the code), it works for any other angle, just not 0.

Signed zero seems to be truncated to positive always

(Thats the bug I'm referring to)

[daniel_lyall]

https://forums.autodesk.com/t5/hsm-post-processor-forum/how-to-set-up-a-4-5-axis-machine-configurati...

[ikcalb]

Thank you for your efforts - but please, no more standardized replies!

I HAVE:

* a working 4 axis post processor

PROBLEM:

I cannot get it to post "G... A-0."

(So for ANY movement, if the desired angle is 0.000° exactly, the SIGN is ALWAYS DROPPED)

As I'm a programmer, aware of different representations of "zero" as a float, I consider this a BUG.

Please forward this to someone with (computer) programming skills.

Thanks a lot & relaxed pre-holidays,

Florian

[daniel_lyall]

Why do you want a -0 

[ikcalb]

For wrapped rotary axes (that can turn in one direction indefinetly), imagine non symmetrical 4/5 axis parts - ie. some part, where a rotation to the left side (say 270°) is only possible in one direction: turning "negative". (turning from 0 to 90 to 180 to 270 would cause a collision on the way)

When the control is taking the shortest path always, one is not able to program a move >180° directly, there always has to be intermediate positions. In order to make a programmed move non ambigous,

TL;DR

some controls determine the intended direction of the move by the sign of the rotary coordinate: if the current position is  `A90`

> `A0` would result in a :positive motion" (moving A91..A180..A270)

whereas

> `A-0` would result in a "negative motion" (moving A89..A88..A0)