x-axis home doesn't work

Matt

Hi. Finally I changed the board and the drives. When I move them, all's fine: but when I home them, z and y axis set home fine, whilst the x axis travels to the right instead of homing to the left, where the stop sensor is. What does this mean?

Samuel Pinches

Dear Matt, this means that the x-axis direction is probably inverted. There is an option in the firmware to change this. Or you could rewire the stepper motor connector to change the direction of motion.

For more info, please see: https://reprap.org/wiki/Stepper_wiring#Motor_moving_the_wrong_direction

Matt

Hi Sam, thanks as always. Probably we are about to solve this damn odissey. This may be meant as a case study in the eventuality of other cases like mine: just change the mobo and/or drivers and you're on. It's cheaper and looks less painful.

One thing though: why should I cnage the wires? Previously it worked, wired as it was by stock. It begun working inversely just once I changed the mobo/drivers. So, perhaps it is more probably a firmware's case. Perhaps JG haves something in their stock firmware which changes the direction of the x stepper only? Though I'm afraid that, flashing their firware in the new mobo, it could crash something else (sorry but began to I trust less and less this "brand").

Samuel Pinches

I would imagine if you flash the stock firmware it will be resolved -- that's the route that I would try first. Or you can try my A5 1.18C firmware on the wiki.

Matt

Well, thus

1) the mobo+drivers work out of the blue anyway, although not completely: at least for what it happens to the x axis (nobody knows whether there should be other issues, unless the whole will be flashed...)

2) so far we ascertained that jg people has the habit to reverse the sense of rotation of the x-axis stepper... Or of the x-home point??? Or of both?

As for your firmware... Well, onestly, I flashed it in once when I tried to find a solution to my prime issue about thez-axis being jammed, and it didn't solved the issue. I reflashed the stock jg firmware and all went back to the normal status (although I had anyway to change mobo/drivers). Perhaps it happened 'cause of the bad drivers.

Samuel Pinches

Did you do a M502 + M500 after flashing? Anyway, I'm confused yet again .... so I'm glad it sounds like you have a solution.

Matt

I don't know what m502+m500 means.

And, no, I'm not sure I have a full solution: I wrote to both aliexpress official supplier of jg and to jg itself: the latter doesn't anwser, the former says he don't know what it could be the culprit...

Samuel Pinches

Well, I am confused about what the problem is that you are trying to solve. You have started a new thread (again) and have mentioned a range of issues from previous threads (again) so I don’t know what we are trying to solve here. Sorry Matt. Need you to make your posts much clearer.

m502 and m500 gcode commands you MUST do after flashing for correct operation. They are clearly explained on the A5 flashing instructions, which I posted on the A5 wiki firmware page.

Samuel Pinches

1) you said they “work out of the blue”. This is extremely ambiguous as to what you are referring to working

2) there is no normal convention for wiring or direction. the firmware and wiring both can be used to invert direction.

3) “prime issues of z axis being jammed” — you are referring to a previous thread? 🧐

4) “ all went back to the normal status”: what does that mean? What is normal? Is that working? Very confusing.

Matt

Hi Sam. I started a new thread 'cause I meant it as new after the chage of the board: also in order to avoid that, if the issue had took another solution in respect to the ones we tried to apply so far, the argument had had been misleading. But if you think that there couldn't be an issue like this, well, perhaps you may move this thread to the original one (the previous thread you mention in your second message), if this is possible.

1. 502/500: sorry, I think I did overgo just about these lines: or some others too. Anyway, it wasn't possible to see whether their applications had worked, 'cause thereafter the printer went no more usable: furthermore there was the bad insertion of a driver which ruined the board, and you know.
2. Yes: I put the drivers in the board, then I moved all axes and they moved correctly (the z axis, to say the truth, now looks to me slower than the original, meant when the printer worked flawlessly: but it may be just a personal impression, 'cause it is now long time that I cannot see the printer operating and I may had forgot how the real pace was). Then I tried to home all three axis and, when homed with the red button, y and z axis homed correctly, whilst the x axis went to the right instead of to the left. I shutted and fired up again the printer, and I tried to home them one per one: again, z and y went ok, but the z again went to the right side.
3. Yes.
   
4. As for "normal status" I mean that it get back to the status which was before the flashing of your firmware, that is a status with the z stepper not working. With your firmware, no steppers was moving: perhaps 'cause I forgot that 502/500 part?

Look, I'm not a techncian, that is one who can use the printer not forcibly making artistic or polished things with it, but at least being able to put hand on the machine when something goes wrong. I'm just a final user: I may have some ability in repairing, but only if I had the opportuinity to check the documentation and workabouts. Though the case it is happening to me perhaps may be banal, for someone who belongs to the tech class and who haves the printer physically in front of him: but there's no plenty of such a class people around me, and when it comes to explain, it becomes somewhat hard to do it, specially if interacting virtually. Or, perhaps, the real fact is that this specific issue has never been stumbled upon by anybody, and the kind of machine (and its buliders themselves...) seems unable to easily help in solving it.

Samuel Pinches

Well, the secret is that I don't know much.... but I apply a strong engineering principle of diagnosis by elimination, and this is often quite successful in troubleshooting. However, for this to work, it also requires that a focus on one clearly defined problem at a time. Perhaps my style is not helpful for you? I honestly, half the time, I have no idea whether I am helpful to you or not!

Matt

Hi Sam, well, you was most helpful to me than many others. I never said that you wasn't or aren't helpful: I only stated (perhaps with great difficulty of expression) that it is ME the one who got problem on grasping some principles, being not a tech but just a final user (or a projectist at most).

Anyway, is that story of the 502-500 to be applied only to the custom firmware of yours?

Samuel Pinches

No, M502 and M500 should be run whenever you flash any firmware with EEPROM support, to reset configuration to the new firmware defaults.

Matt

Ah I see. This may have any involvment with the x axis moving in reverse?

Samuel Pinches

I've seen all kinds of weird things happen when these commands have not run. All I can say: maybe.

Matt

P.s. which page is the one of the firmware? https://jgaurorawiki.com/a5/factory-firmware?

But, the instruction for m502/500?

Samuel Pinches

This one: https://jgaurorawiki.com/a5/firmware

Matt

Thanks. Though, it is still very strange that all drivers worked p&p but the x one, and just when homing.

Ok. But... Shouldn't the firmware get flashed through Cura? What us that IDE?

Samuel Pinches

If you are flashing a pre-compiled bin file you can do through cura. If you are compiling and flashing, you can do both from Arduino IDE.

Matt

And the precompiled one has 502/500?

Samuel Pinches

No. Still needs the same commands sent after installing firmware IF it has eeprom support enabled.

Matt

and how can I see if the eeprom is enabled? this means though that it must be done anyway through arduino?

Samuel Pinches

If it is original factory firmware then eeprom will be off, as far as I know. If you’re flashing with a community firmware, then eeprom is enabled by default.

Matt

Ah, ok. Btw, you know? I still got no luck, it seems: to dl arduino I had winupdate enabled, but apparently in my pc this cannot be done due an error (for which I was unable to find any solution even in the MS "knowledge base")...

So, it seems that I have to flash the factory firmware :-( Hoping that it will work.

Anyway, believe me: this "case study" is ennoying me and my morale is surely more and more down with this printer.

Matt

Ok, the jg guy answered me finally, telling me to" try" with flashing their firmware. Tha fact that they don't even know what's up, confirms my opinion about them.

Samuel Pinches

Matt, please don't be quick to judge people. Are you online now?

Matt

I'm online now. Trying to flash right now.

It is not that I'm quick it is just that I recognized so far just inability or scarce interest to solve the issue with precision, from them.

Matt

Trying to connect with cura 4.8.0, but it says that a connection cannot be established with the printer. There should I use a older version of Cura, like in the video?

Matt

Tried to flash, I had to use the old cura version of the video, as the jg guy told me too: he sent two versions, but neither works apparently. Albeit all axis are now working good, when I try to print a test, the printer stops and beeps a beep like the one of the filament runout. i had to flash in their 'cause no copy of the ones from the links supplied in your wiki worked (also featuring 404, besides bringing me to a repo where I don't know what to download from).

Matt

This is comic: the guy answered me to remove the filament sensor to end the beep! And you still say that I shouldn't be "biased"? They don't even have a clue on what happens to the machines they build.

Matt

I really don't know what's up and what to do.