Printer communication problems

sandersen

Hi, I could use some help.

I am building a 3D-printer based on the a UDOO quad with RADDS 1.5 shield, lcd and RAPS128 drivers

But I have multiple problems I can´t solve.

1: I can't get the SD reader to function. I have tried multiple SD-cards below 2gb, all FAT or FAT32. When I insert the card the display writes "SD inserted" but controls slows (almost freezes ) and I am unable to locate any files.

2: I am also unable to controll the printer through USB. Neither pronterface or repeater host works.

https://dl.dropboxusercontent.com/u/5750994/Configuration.h

Repetier

With lcd configured only the sd slot at the lcd works. Make sure cable is not near any other electroic parts with high currency and all connections are good. You are catched in a insert - mount - fail mount loop whcih takes all cpu power. When that happens the firmware gets unsable.

If your baudrate is 250000 you will get problems with host. Try Repetier-Server instead which also supports 250000 baud. Also make sure to connect to the right port (normally programming port) or you will also fail if you compiled firmware for native port. Not really sure if that usb port on udoo is programming or native part.

sandersen

Thank you very much for your reply

1: I have tried and checked everything you suggested without any results. And I also have another problem now, the display has stopped working. The background lighting and the controls still works but it doesn't display anything. I will check the cables again but I what else to do?

2. My baudrate is 115200. And I dont think baudrate is the problem.? I can connect to the printer an receive messages like "SD init fail" but I can't send any communications the other way.

I am almost certain that I am using the programming port.

Repetier

If you receive SD init fail baud rate is correct. Then you are in a sd startup loop. Remove sd card and try again.

Latest 0.92 firmware has now a switch

/* Some displays loose their settings from time to time. Try uncommenting the

autorepair function if this is the case. It is not supported for all display

types. It creates a minimal flicker from time to time and also slows down

computations, so do not enable it if your display works stable!

*/

//#define TRY_AUTOREPAIR_LCD_ERRORS

which you should use. This reinitalized display on every refresh so it reverts from errors caused by bad communication, also it is still unclear why you have these error at all.

sandersen

Thanks,

I got my display working again just by changing firmware. I have been changing between 0.91 and 0.92 without any noticeable differences.

I have tried several different sd cards all between 1-2 gb and I have tried both FAT and FAT32 without any luck. It always gat stuck in the sd startup loop.

Repetier

Not sure what you mean. With 0.91 the display works and 0.92 not and sd card with none?

YOu could try in ui.j

#if FEATURE_CONTROLLER == CONTROLLER_RADDS

#define SDSS 10

#define SPI_PIN 77

#define SPI_CHAN 0

commentin the 3 defines for sd card. Then the sd card on the radds gets active. So you can see if your sd cards will work. If they work there they also work on the display if connection through display and solderings etc. is good and no interference from long cable ...

sandersen

I solved the connection problem by ejecting the UDOO's sd, making it unable to boot linux. So the connection problem was caused by interference from the board computer.

Repetier

You mean the sd card connection problem, right?

sandersen

Sorry I was a bit unclear. I managed to connect by usb cable. The UDOO uses a seperate sd for OS, the one I ejected.

I haven't been able to solve the SD problem. Do you have any other suggestions about what could be wrong.?

Right now I am running 0.91 and I am experiencing some odd things. It seems like the display stops working after connecting by usb.

Another thing; I use two motors for the x-axis and each motor has its own driver. Everything works perfectly when moving the axis through the controls on the display. But when I use repeater host or pronterface the "secondary" x-axis motor locks making it impossible to move the x-axis. The motors are mirrored and mechanically synced. can you explain this?

Repetier

UDOO: I still need to install my udoo to test things, but I'm so busy I don't know when.

x mirror is done in step and unstep. LCD and external control use the same move routines use the same functions in the end, so it makes no real sense. So at least with same speed both motors should work the same. If not try loosing belt and see if they maybe rotate in different directions or turn in same direction with different speeds. In latter case the stepper driver would be loosing steps and increasing STEPPER_HIGH_DELAY may help here so driver recognices the signals. Some drivers need certain high times.

sandersen

Understandable. It is har to find people who have experience with the UDOO for this application.

I have just triple checked. The printer behaves as I said. When I connect with repeater host something changes and the mirrored x-motor just becomes stationary. It is powered but won't move. I have tried increasing the delays but without any results It must be something in the firmware or eprom i think?

You dont have any further suggestions about the SD problem?

Repetier

Are you using latest 0.92 version? I remember there was a problem with one mirrored motor, just not what exactly. As you see in this code

inline void startXStep()

{

#if !(GANTRY)

WRITE(X_STEP_PIN,HIGH);

#if FEATURE_TWO_XSTEPPER

WRITE(X2_STEP_PIN,HIGH);

#endif

which is used to set a step there are always both set. Same in

static INLINE void endXYZSteps()

{

WRITE(X_STEP_PIN,LOW);

#if FEATURE_TWO_XSTEPPER

WRITE(X2_STEP_PIN,LOW);

#endif

WRITE(Y_STEP_PIN,LOW);

#if FEATURE_TWO_YSTEPPER

WRITE(Y2_STEP_PIN,LOW);

#endif

WRITE(Z_STEP_PIN,LOW);

#if FEATURE_TWO_ZSTEPPER

WRITE(Z2_STEP_PIN,LOW);

#endif

}

and since they have power this should work especially if it works form lcd. To make it not work you would need to make the stepper signal a input.

sd problem is not solvable if it is interference with udoo board I guess. In that case you would need to use the server software instead. After all you combine it to not use the sd card.

sandersen

I am using 0.92.3

I can't grasp this bug but somehow after I was working on the UDOO. it managed to fix it self. I didn't make any significant changes in the firmware but I changed the OS from lubuntu to debian. I decided to change to debian since it is what Angelo uses (the guy who sold me the UDOO and the RADDS).

But prior to that the LCD controls "changed" to do the same odd thing as in host after connecting.

Thank you for the code it might come handy if my current setup proves to be unstable.

The lcd seems to be stable with 0.92.3.

Regarding the SD problems I will try to contact Angelo.

I will keep you posted.

sandersen

Okay, the motor problem didn't solve itself.. It works when I shutdown the OS (debian) on the UDOO manually. If I prevent it from booting by ejecting the sd the problem occurs.

To sum it up:

- When OS is running I can connect but I can't send instructions, only receive

- When I prevent the boot by ejecting the SD (sd on UDOO) I can connect and send instructions but the mirrored motor won't move

- When I shutdown the OS Everything works as it should.

I have a hard time making sense of it, I might try and change the mirrored x-axis motor to E1 just to try it out with different pins.

Repetier

Sounds like the os is setting some pins on it's own making it hard for the firmware. I know there are 2 ways for udoo to connect to serial. Have you tried externally also for os?

sandersen

As far as I am aware the A9(quad core microprocessor) and M3(DUE microcontroller) only share two serial connections which corresponds to the M3's programming port and native port. I can reroute the connection by unplugging a jumper on the UDOO.

If I let the jumper sit I should be able to connect to the A9, but I don't have any use for this right now. My plan is to get everything going with the M3 before exploring the A9.

I have tried to connect with printrun without pulling the jumper, and I get a logon request from the linux.

The M3 should have all the pins connected to the RADDS - I can't see how the A9 should be able to interfere.? or am I missing something..?

Repetier

I guess I should soon start using the udoo so I can follow you and test myself.

garyacrowellsr

Doesn't the A9 and the M3 share a bunch of GPIO? Maybe the A9 isn't keeping it's hands off one of the motor control pins. Please keep posting your progress - I also have a UDOO but haven't done anything with it yet.

Repetier

In fact they share nearly all pins. Depending on A9 config they get shared or not. Setting the wrong one to shared can even damage pins e.g. setting an input to output.

My UDOO at least compiles but I have no printer to put it in at the moment, so I guess it stays stand alone. Will only attach a radds with display to it for testing communication. Others have managed it so it should be possible.

sandersen

The printer is now up and running with Repetier Server, running on Debian Wheezy. It works nicely - quite responsive :)

The firmware setup is the same, no conflicts. I haven't solved the SD problem yet but it isn't highly prioritised now because using Repetier Server is more convenient.