UVW Axis limit switches, documentation missing, configuration missing

[prof7bit]

In the wiki it says the edge branch supports 3 additional linear axis: U, V and W

I have bought an Arduino Due and the recommended(!) Djuke 6 motor shield in the hopes of being able to drive a machine with 4 linear and one rotational axis.

After having to modify 3 undocumented source code files to actually use the advertised 6 motors instead of only 4 to make any use of the djuke 6 motor board at all (lost half a day on this) I am now facing another problem: While the 6 motors can be mapped to any of the 9 axis the limit switches seem (according to the labeling on the board) to be hardcoded to certain axis (XYZABC) and can not be mapped like the motors. The outputs for the motor drivers are labeled with motor numbers 1..6 and intuitively I would have expected the limit switches to also be labeled 1..6 and bound to their respective motors (which would reflect the real world mechanical situation of the machine and the cabeling) and not hardcoded to certain logical axis xyzabc.

Question: Is the labeling just wrong and the limit switches are indeed bound to the 6 motors and will automatically be remapped when I map the motors to different axis (this would be the only logical behavior)?

I cannot find any documentation regarding the assignment of the limit switches at all.

I cannot find any configuration file for the limit switch assignment. An older post somewhere on the web mentioned settings of variables like kXAxis_MinPinNumber, kYAxis..., etc. but a full text search in the entire code base suggests these variables do not exist anymore, their names only appear exactly once in a "shopbotShield" file and referenced nowhere else in the code.

So this bug is actually multiple bugs in one:

• Misleading advertising in the wiki (9 axis, 6 motors) while in reality only 4 motors are supported and c++ code (not just header files) has to be added and existing code has to be modified to make the missing 2 motors appear. It should not be praised in the wiki as having certain features unless these features are actually implemented. People might spend real money planning and buying hardware, believing there is hardware and software for their 5 axis machine as advertised in the readme and wiki only to find out it does not work as advertised at all and really supports only 4 motors.

• Zero documentation about limit switch assignment and configuration

Edit: (3 hours later and calmed down again) I finally found some documentation mentioning it, from this I could infer how it is meant to be used. For some reason I did not find it the first time looking for it, probably because I was frustrated from staring at all the code for hours, trying to trace back where all the defines are located and what includes what.

[justinclift]

Ouch, that all sounds super frustrating. 😦

With the limit switches, they're "Digital IO": https://github.com/synthetos/g2/wiki/Digital-IO

Now you mention it, we probably should have a page dedicated just to limit switches. Half the problem with this wiki is there is a lot of information in it, without a good way to search it. 😦

With your modified files and configuration, have you pushed that to a repo on GitHub? If so, I can take a look over it and see if any gotchas stand out.

(Note - personally I haven't really touched g2 in a few months due to my gear being at a local Makerspace and my city being in a coronavirus lock down. I was able to pick up the gear yesterday, so am starting to come back up to speed with it now... )

[prof7bit]

Ok, I have found how this is meant to be used: There is a setting for each axis where I must enter the number of a digital input. This is the limit switch for homing probably what is meant by *_min, I have not yet figured out how I would configure the *_max limit switches should I ever want to use them, luckily I wont need them probably.

I have wired up and configured the first axis of my machine and so far it is working as intended.

The gshield compile configuration which is supposed to be used when compiling for the Due/DJuke combination defines 12 inputs in its settings header, these inputs are routed to two 12-pin connectors on the sides of the DJuke shield and are labeled xmin, xmax, ..., cmin, cmax, I have checked the pin numbers with the help of the schematics, they are all defined correctly.

Of these 12 inputs only the first 9 will work out of the box, there is a setting in gpio.h that must be changed from 9 to 12.

There is a lot of stuff in the edge branch that does not seem to fit the DJuke shield. So far I have found the following 3 problems:

• Only 4 motors enabled in the edge branch, entire sections of code are commented out, fortunately it can be fixed, there is a small syntax error in one of the commented code blocks that will cause crazy compile errors in different places but it can be fixed, all 6 motors seem to be generating pulses and come out of the proper connectors on the shield.
• Spindle direction pin is not configured
• Only 9 inputs enabled in gpio.h instead of all 12 on the shield and in the default settings header, this was quite confusing and took me some time to find out, it looked like they were properly enabled but there was another setting in another file that silently interfered with it, the organization and purpose of various configuration headers and which ones are supposed to be edited can be quite confusing.

I have found at least 2 old bugs from years ago that mention these problems, they are still open.

There is a fork from DJuke but it only fixes the spindle direction problem, I am using the official edge branch from here.

[justinclift]

There is a lot of stuff in the edge branch that does not seem to fit the DJuke shield.

Ahhh, that's a good point. I've been meaning to order one each of those shields (1x onboard drivers, 1x external drivers) to get some hands on experience with them too. Sounds like I'd better get that done sooner rather than later. 😄

[prof7bit]

When the number of inputs/outputs can change for different boards it should probably not be defined in a global configuration file and should be moved into the board-specific headers.

When less then 6 motors are to be used it should probably also be defined on a per-board basis with a simple define of the motor count and let a bunch of ifdefs in other places do the heavy lifting of removing code blocks in various places for unused motors.

[justinclift]

Good point. Not sure why they are that way... it might be for a specific reason, or could just be some left over legacy thing. If it's just a left over legacy thing, it's probably fixable. 😄

[prof7bit]

Is there a computational cost associated with leaving all 6 motors enabled or is it just the size of the binary? I didn't notice any dramatic differences at all. If there is no reason to remove 2 motors for certain builds then maybe the code for them should just always be enabled, this would make it much easier.

[justinclift]

Personally, I'm not sure. @giseburt would likely know though. 😄