Skip to content
This repository has been archived by the owner on Aug 27, 2023. It is now read-only.

Teacup not setting Y-MAX correctly after homing against the Y-Max-Switch #325

Open
arcimede opened this issue Mar 17, 2020 · 13 comments
Open

Comments

@arcimede
Copy link

HI
I have setup my Hardware (644P,20MHz) for an old RapMan 3.2. Until now it seems that most is working fine....
The only thing is, that if the print head is homing against the Y-MAX-Switch (this is how the RapMan design is!). The new Y-position is somewath like 3.384mm instead of 200mm as I configured Y-MAX. If I set the Y-MAX value to 205 the Y-position is 8.384mm! This is not a real problem, since I can set the rigth value with G92 Y200, but it would be nice if the controller would do that by himself!

Saluti Joerg

@Wurstnase
Copy link
Collaborator

but it would be nice if the controller would do that by himself!

It should. Can you please show printer and board file?

@arcimede
Copy link
Author

Hi Nico
here are the files in pdf-format

printer.rapmanjs.h.pdf
board.js1.h.pdf

I noted also that if I not was defining the Y_MIN value, the printer moved the Y-axis even if I wanted to move only the Z- or X-axis.... this behavior stopped when I defined the Y_MIN value to 0 (zero)... but the setting of the new origin was how i described earlier..

I created the hardware by my own based on my 40 years of experience as engeneer in electronics/mecanics so I think it is rather a software problem than hardware... but it may be also my fault...

Saluti from southern Switzerland Joerg

@Wurstnase
Copy link
Collaborator

Can you please send a M119 to report the endstop status. Before sending, be sure, that no endstop is touched.

@arcimede
Copy link
Author

There it comes...

after Reset
x_min:open y_max:open z_min:open <\n>ok<\n>

20200319_130826_resized

and the same after G28...
x_min:open y_max:open z_min:open <\n>ok<\n>

20200319_131601_resized
Saluti Joerg

@Traumflug
Copy link
Owner

A couple of days ago I got this from a customer:

I did find one bug in line 92 of the data.py file controlling "reFloat" formatting for printer max and min sizes. I added -? to it to allow negative numbers. The current formatting did not allow negative numbers. This is what I think it should be:

reFloat = re.compile("^-?\d+(\.\d*)?$")

@arcimede
Copy link
Author

Hi
I don´t think it´s the configtool.
looking after X_Max in all files (about 47 including the ones in the config directory), I see that the settings seemed correct. For me the home_position_Y is also set correctly. I think somewath is messing up startpoint.axis[n].
It may be in dda.c or gcode_process.c.....
But this is only a guess...

@Wurstnase
Copy link
Collaborator

Did you have the same issue with G28 Y as command?
Can you please upload your files not as pdf? I need normal header files to make some tests.

@arcimede
Copy link
Author

Good morning
I tried G28 Y -> same as before....
Here the files with .txt added

board.js1.h.txt
printer.rapmanjs.h.txt

Sorry for the pdf´s, but I am not very familiar with GitHub.... (gut Ding will Weile haben...)

Saluti Joerg

@Wurstnase
Copy link
Collaborator

Got it. A simple overflow. I will push an update.
Just fixed in the experimental branch.

@Wurstnase
Copy link
Collaborator

Btw. It is always a good idea to compile it with -Wall

  CC        build/home.o
home.c: In function 'set_axis_home_position':
home.c:197:37: warning: integer overflow in expression of type 'int' results in '3392' [-Woverflow]
  197 |       home_position = (int32_t)(Y_MAX * 1000);
      |                                     ^
  CC        build/i2c.o

3392 is your 3.392.

@arcimede
Copy link
Author

I did the same modification and it works.
Thanks, but I had also a look to all the files and found other calculations with constants like 1000, so I think one would have to check every case and define the constant as long with the L at the end!
I also noted, that Teacup does not start when I do not connect the 4-bit-bus LCD display. Most probably the software is waiting for the BF bit (busy flag) of the display controller; since i programed some drivers, i know the case. I will check this and maybe a timeout is needed.

Saluti Jörg

@Wurstnase
Copy link
Collaborator

Wurstnase commented Mar 31, 2020

The issue in this case is, that both values are < 16bit (sizeof(int) on AVR) and defines. In this case the compiler will set both to int and make the multiplication which will overflow.

Currently I don't find any place with the same issue. But any hints are welcome.

@arcimede
Copy link
Author

Hi Nico
I thougth that Y_MAX is floating.... (defined 200.0)
and I hope that in the delay.c file this does not cause any problems -> delay_us(delay * 1000 - 2);

Jörg

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants