Closed whatwouldiando closed 2 years ago
RaphaelDives
commented
2 years ago Hello @whatwouldiando, Congrats for the lowrider! I’m a proudly owner of a Mpcnc. 😉 I would just guess that there’s an issue with the parameters for the cloned axis, but since you wrote that they are identical, I have no clue. But anyway you should post the parameter output and the changed part of your config.h. Cheers Raphael
fra589
commented
2 years ago Hi @whatwouldiando,
You understood well, as your axis names are X, Y, Z, Y and Z, 4th axis will be cloned with Z and 5th with Z.
You will have 5 linear axes and therefore, your definition of N_AXIS_LINEAR = 5 is good.
I don't think this can be an UGS problem as it just send X, Y & Z GCode commands and it does not have to worry about the internal definition of grbl-Mega-5X firmware...
The behavior you describe seems to me like a corrupted memory flash parameter... I never seen exactly the same behavior, but I have already noticed that Grbl can have realy unpredictable behavior after changing the version or after changing any axis definition.
After flashing Grbl to the board, it's important to issue the $RST$* command to clean and reset the flash parameters memory to the defaults.
Do you issued the $RST=* command ?
As @RaphaelDives wrote, please send the output of the $I and $$ Grbl's commands and an extract of the modified parts of your config.h file. so, I will can try to reproduce your behavior and understant what happen.
@++; Gauthier.
whatwouldiando
commented
2 years ago yes im sorry i forgot to mention that i did use the $RST=* command each time i re flashed the firmware. Im sorry i dont follow the "I and $" commands? I get the $firmware setting parameters, but whats that first part? I will try to copy the exact code excerpts from that computer and email them to myself so I can post them here. Internet at my shop is shoddy. Also I have no concrete understanding of the EEPROM, does anything need to be cleared or reset with that if I change the firmware? Also one more issue with UGS... I can jog it ok in the setup wizard, but in the normal jog controller even with the jog set to .1 mm and the axis max travel set to the default setting, trying to jog gives me an error stating the jog command is beyond the machine travel.. which seems to make no sense as the default is I believe 400mm. maybe this is perhaps because it has not been homed? but even that doesnt make much sense because i changed the max travel to a larger setting like 2500 and then it will allow me to jog. I could try and capture a video of this movement but Im not sure if thats something i can post here. I will try and get all the relevant info up here tomorrow. I'm planning on spending the day on this to try and get a little further along. Thanks for the quick response.
whatwouldiando
commented
2 years ago oops lol. I apparently don't know how the syntax on posts works here either...
whatwouldiando
commented
2 years ago sorry i just read the config.h more thoroughly and realize now the "$RST=*" command is what wipes the eeprom. One question though, I see options for limit pin invert masks but I am not seeing an option to invert all limit pins... I'm guessing I just need to use $5=1 in UGS? I am using normal closed limit switches. It is my understanding that these can still be connected from pin to ground with internal pullup resistors enabled and the logic simply changes from high active to low active. I have read a lot of different stuff about external pull down resistors and it seems there is a lot of conflicting info on that topic. It seems to me that I would only need a pulldown resistor if I had a normal open switch and connected one side of the switch to Vcc and the other side to my pin with logic for the input being low = inactive and high = active, thus wanting the pulldown resistor to make the pin not be in a floating state. But to confirm so I don't fry any pins or anything, If I use $5=1 does this only invert the logic of the limit input pins? As in low = inactive and high = active? I just want to be sure it does not invert the default pin setting of being set high with the internal pullup resistor enabled.
whatwouldiando
commented
2 years ago These are the only changes made to the config.h file. I have not made any changes to any other files. Unfortunately I had to bring the shop laptop home to upload this as I have no internet there, so I can't upload the $ firmware settings without being connected to the machine. I will have to get those when I go back. In regards to my last question, what is the difference between
and $5=1 I only have limit switches at one end of each axis and I understand default it will home to max so I have wired them to the pins in cpu_map for Max limit pin. but I want to invert the logic for normal closed. Also another note, I was messing around today with UGS setup wizard and noticed that when I selected reverse direction for y or z in the wizard (since I want it to recognize the direction that moves toward limits as being y+ and z+) it only reverses the first y and z not the second ones, axis 4 and 5. Not sure if this is a big deal as I was able to correct by changing $3=8 (inverting my second y motor, axis 4) to $3=22 (inverting axis 5, 3, and 2) since both y and z need to move the opposite way to go toward the limits. But just curious as to the reason for this. I guess UGS doesn't realize on its own that 4 and 5 are clones, so I feel like I should stick to manually altering behavior with firmware settings.
// Axis indexing and names
//#define HOMING_CYCLE_1 (1<<AXIS_1) // Home X axis // OPTIONAL: uncomment to move only X at a time.
//#define HOMING_CYCLE_3 (1<<AXIS_4) // Home 4th axis (A) //#define HOMING_CYCLE_4 (1<<AXIS_5) // Home 5th axis (B)
whatwouldiando
commented
2 years ago sorry to waste your time. i figure out my main issue. I have a bad stepper driver. only getting 2 volts instead of 12 to the B coil out of my y drive. I swapped the connection to the other driver and then the other motor was the one behaving strange. Putting a volt meter on it showed me the problem in the end after I checked all my wiring. I ordered a new one and should have it monday. As far as limits are concerned I will make a separate post if I have any issues, So far I have good readings from the volt meter and I think I have settings correct in config.h. I just need to get controller to register them. Now using cncjs instead of UGS since it was crashing repeatedly. But cncjs doesnt seem to show limit switch states as far as i can tell thus far.... its a process but im getting there one step at a time. Thanks for the help :)
RaphaelDives
commented
2 years ago Hey @whatwouldiando, I‘m glad that you found your problem. For the current limit switch states just send a „?“ via command line. I‘m quite happy with bcnc by the way. Cheers Raphael
whatwouldiando
commented
2 years ago Quick question...
#error "INVERT_LIMIT_PIN_MASK is not implemented, use INVERT_<MAX|MIN>_LIMIT_PIN_MASK"Does this mean $5=1 will not invert logic for limit switches and I must put in the following in config.h to get inverted logic for NC limit switches.
whatwouldiando
commented
2 years ago Turns out my stepper driver wasnt even the problem. I had a loose connection this whole time. They are moving smooth now... Until I try and alter the step/mm. Going to open a new issue about that.
Bear with me here I am pretty novice still, but I have read about every post on every forum even closely relating to my situation and I can find anything on this issue. I have a Lowrider3 cnc router I'm building and have it set up with arduino running grbl-mega-5x. I'm testing with universal g-code sender. Thus far I have finally got motors moving. But jogging along the table one of my y axis drives moves the wrong direction for a few steps before beginning to move the correct direction. This mainly seems to happen when I jog in the oppossite direction from the previous jog. If I continue jogging the same direction they both move together just fine. I can't for the life of me think of a logical explanation as to how this could happen. I am soon to try a different g code sender as UGS has already crashed numerous times while I've been trying to get things set up and calibrated. Perhaps its something wrong with that and not grbl-mega-5x who knows. But I can't find anything about anyone else having this behavior on their machine. Just to be totally clear and make sure I have my understanding of thing correct and that I have set up everything right, I will give a brief description of my setup and process followed thus far:
For those not familiar with the lowrider 3 cnc from v1 engineering, it has two belt driven y motors, two screw driven z motors, and one belt driven x motor. I changed the config.h file only minimally so far, renaming axis 4 from a to y and axis 5 to z. Its my understanding that this will have the affect of cloning the 4th and 5th motors to those axes. I also changed num_linear_axes from 3 to 5. Not quite sure about that one but I saw a post that since they are not rotational 4th or 5th axis this is how it should be, hopefully I understood that right. Finally I changed the homing cycles to home the cloned axes together, each in separate cycles, z then x, then y. So far I haven't even got around to testing homing, I still have to get my limit switches working right. So to be clear this is not an issue with movement during homing. Finally in UGS i made sure all setting for the cloned axes matched those to the first y and z drives. I have no issues with the z drives, they both move together and in the right directions. I did apply one direction mask to invert the direction of the second y drive, if I remember correctly $3=8. (sorry I don't have the machine or computer here at my house they are at my shop location) This mask correctly changed the mirrored y axis to move in the opposite rotation, making both drive the machine the same direction along the table. (belts are routed on opposite, mirrored orientations to the motors) At this point I was just testing jogging motors back and forth several times. If I jog y+ they both move together one way, y+ again they again move together the same way. But if I then jog y-, the first y axis continues in the + direction for a half second or so before switching directions and moving in the - direction along with the second motor. continuing in the - direction they again move together correctly. switching back to + after jogging negative, again the first y motor moves - first for a moment then switches to moving +. This appears to only be happening with the first y motor, which is programmed and connected with the pinouts for axis 2. The second y motor (axis 4) seems to correctly respond right away in the correct direction. I still have to test this more to see if any other jog movements or combinations exhibit strange behavior, and again I suppose its possible UGS is the problem. I just wanted to put this out there to confirm I set up firmware correctly to rule that out, and perhaps see if there is some logical explanation for this type of behavior. Any advice is much appreciated.