NanoDLP Connectivity and Power Issues

[Elliot McAllister]

Hi All-

I've upgraded to the NanoDLP and am excited about getting printing with the new functionality.  I seem to be facing some inconsistent connectivity issues and now power issues with the 3DP.  As well possible RAMPS issues carried over from the original set-up

Yesterday we tried printing several times, and after a long set-up time and manual entry of many of the settings here is where I am at:

Nanodlp would not allow - distro change to mUVe 3d.  This was done manually through set-up.

We were able to get the printer moving, homing and appearing to do some of the correct steps.  Last week just prior to making the switch I thought I had an issue with one of the z-axis motors (the one not connected to the end stop would continue to move - while the one with end stop was stopped. (This was from the home position during a print - so it looked like it would be doing the tilt/drain move.)  Made me think I had a stuck end stop.  The issue seemed to have cleared but now it is back.

Since making the switch to RasPi, we have issues finding it on the network.  Even re-boot of computer, RasPi, Router and flashing the router refresh.

Projector connectivity was not possible through RasPi - and the projector was apparently not found as the image displayed was only of the splash screen - not any slices were shown.  Connection to projector was not able to be saved except for USB0, no other selections were saved.

Stepper motor  for shutter seemed to be "re-homing" during set-up. meaning the open and closed positions kept moving to one side or another - never returning to the same location - could be power or pulse width.  Set-up was to have power from Arduino in mUVe, signal from the Ras-Pi.  Split the 3 way connector for the servo running power lines, then the signal from RasPi.

What we tried to correct the issues:

1. I've done and re-done the RasPi set-up as per the web instructions: 

Here is what I have found:  I need to install Rasbian Jessie and then flash with nanodlp image after downloading both while SD card was mounted in the PC for both.  (I was not able to download from the web direct onto Pi because for some reason when this keyboard is hooked upto Pi, I cannot get it to make the | symbol.  Don't ask - I tired nearly a dozen ways.  So I am hoping that not being the lite version is not affecting anything - can't say that it would.

2. When I had it originally set up, I was able to find the printer online and through my computer network.  Now it seems unreachable, even re-booting several times as well as refreshing the router.

2b. cannot find it by typing in the IP address either. - so it seems that it is not on the network...This issue was consistent in the first and second attempt.

3.So I couldn't connect and it wasn't driving. 

When I hook mUVe back up to the PC, Creator crashes with a small flash screen that mUVe3d is not working properly.  Orignially when I first tried this - it would not connect, Control screen remained blank.  Believe this to be because new firmware for nanodlp compatibility.

4. Now the fan and motors have now power.  I am concerned I did something to the board - but -  the Arduino seems to be ok (two green flashes when re-starting and a constant green after.

5. I checked the endstop, with power off, disconnected and reconnected.  Double checked the connnections to the motors as well (I had a loose connection one other time).  Hand turned the lead screws to clear above the lever arm, clicked the end stop several times. Still no power.

6. Double checked all the connection cables (again had one connectivity issue previously where the cable was loose).  Issue remains.

7. Complete power down disconnect cables.  Issues remain.

[mUVe 3D Admin]

Elliot,

By the sounds of things you have several issues that need to be sorted out individually before trying to proceed with any testing.

1. Your keyboard locale on the RPi needs to be changed so that the keys are mapped properly. That's why you can't find the correct symbol. "sudo raspi-config" from an SSH terminal will allow you to configure it.

2. This sounds like your Raspberry Pi power supply isn't working well enough. If it worked initially and now it won't, this is likely the cause.

2b. Still sounds like the power supply isn't at least 2A for a RPi2 and 3A for an RPi3.

3. If it's not connecting from the PC then this signals that the firmware isn't correct. If you installed the latest version did you follow the new instruction in the firmware readme?

5. Still sounds like incorrect firmware or firmware config. Check everything and reflash your Arduino to be sure.

So it doesn't sound like your power supply or USB wire for the Pi can supply enough power, and that your firmware isn't setup correctly. Either that or something bad happened during the setup and they're both fried. That would be the only explanations that we can come up with that would support this behavior out of the electronics.

Best of luck and if you end up making any progress let us know. We'll be here to help.

mUVe 3D Support

[Matthew Caron]

Replying using your numbering:

1. Make sure to use Jessie lite. As I understand it, this is the new standard. You mention Lite in your comment, but I want to be certain.
1. You need to make sure to set the region for your keyboard correctly. This can be done through raspi-config. See my notes, which may prove helpful.
2. If you're not doing the NanoDLP setup on the RPi, then the setup script will not likely work unless you've done something very clever with a chroot-ed environment and an ARM emulator. This is likely the cause of much of your problems. I'd wipe the SD card, start from scratch, set up your keyboard properly, then get everything working per the standard instructions. Otherwise, you're likely to break your main PC too, as the setup script pokes around and modifies your /etc/ files.
2. It may have gotten a new IP address. Depending on how your network is set up, you want to do one of:
1. Set the RPi to use a static IP.
2. Set it to use DHCP and have your router always give it the same IP with a DHCP reservation.
3. Use a router which automatically updates DNS settings with the assigned IP address. So, the printer asks for an IP and provides its hostname. The router gives it an IP and then adds a DNS entry for that hostname and that IP.
3. I have no idea, I've not used Creator with the latest firmware. You may be right and backwards compatibility is broken.
4. There are two sets of power inputs - the Arduino can actually run just from the USB power. Then, there's a secondary power connector which drives all the motor chips. It's possible that has become unplugged or otherwise disconnected. I'd check the wiring. The fan is the big indicator here - if it's not spinning, the motor board has no power. Break out the meter and trace it through. Do you have a voltage across the screw terminals for the green power connector? If not, then you need to trace it back further - check the barrel jack coming out of the power brick, etc.
5. I don't think any of this is going to do anything until you've fixed your power issue. That said, I did have an issue with an endstop I had plugged in backwards which caused a short and stopped the board from powering on. You can test this by unplugging the endstop,
6. See item 4 - it's meter time!
7. See item 4.

[Colen Casey]

as far as finding it on your network
mine did not come up on the Network screen of I/E

I just sent to my router looked up the ip table for assign devices and found its ip number
then I told the router that that device always gets that IP number (reserved it)

so now I know 192.168.1.5 is my printer
you can then make a short cut to it

[mUVe 3D Admin]

All,

Your router needs to support UPnP and it must be turned on for the UPnP network discovery function to work for you. On your PC it is also possible that you have network discovery turned off. If you check both of those and make any necessary corrections it should make it so that the printer can be discovered in Windows Explorer or your particular OS's network/file browser. Then it's no issue to use DHCP and let the addresses change as your router see's fit.

mUVe 3D Support

[Elliot McAllister]

Thanks guys!

OK:

1. Raspberry pi with Jessie-lite has been installed as well the image of nanodlp.  This checks out and initially could see the nanodlp on the network.  And yes Matt, I believe you are correct from an earlier post.  I saw the mention of issues re: graphics from regular RasPi install and immediately moved back to the lite version.  Thanks admin in the keyboard layout, I will have to look into that next time I use a Pi.  (Once the nanodlp is installed there is no terminal - but maybe there is a key entry to get back to it).

2. In nanodlp, selected printer/distro - as some others have mentioned it kicks me off the link and I missed the RasPi lights to know if was just reboot etc.  But seems to have taken - though now UPnP does not seem to find the nanodlp.

3. I believe it is the firmware upgrade that makes it no longer backward compatible to Creator - but now that the above issues are solved, I don't need to look in Creator for the issues.

4. Power issue...Ohvey!  Loose plug - to the suge protector... sheesh!  Must have checked that 3x but obviously not well enough.  Tight enough to issue power, loose enough to have connectivity issues.

5. Still have a nutty end stop issue I believe.  The printer turned on, powered up but now when asking to home it moves up about 1-2mm and will move up any integer selected from z-axis calibration...however will not home (only moves up again 1-2mm) and will not move down.  I think I prolly missed a setting somewhere because this is a new behavior.

6. Again with the projector connectivity issues - still have the nul-modem connection in line, tried a straight pass.  I'm thinking it's a re-boot and connection issue again as it was a few months ago.

Thanks again!

[Matthew Caron]

1. Actually, there is a terminal of you SSH to it, and I believe it uses the system-configured keyboard, and not the one connected to the SSH client (which is weird, but, IIRC, this is how it works. I also could be very wrong).

2. That sounds like a voltage sag and power reboot. How beefy is your power supply?

4. It's always the little things. Say, is your RPi brick attached to it also loose?

5. Do you have the old or new endstop? Did you see the note about having to change a define in the firmware?

6. I've never had luck with USB serial converters. I always fry them (not in this application, but just in general). Basically, the only way to really debug this is to ssh into the RPi and do an lsusb to get a list of the attached devices. You should see both your USB converter and the RAMPS. But, it should be a null modem cable. Now, I will also note that I have seen instances where the projector wouldn't always turn on via serial, but would always turn off via serial. I think sometimes it's "really asleep" or something.

[Elliot McAllister]

Ok, I thought everything was working but now I am right back to some weird and incorrect behavior from the printer - which is why I re-did the above last week.  

Responding to Matthew:

power supply should be good.

RasPi is solid mounted

same end stop from the original order, but very low hours on it.

projector with null modem is good, when connected and on computer network the projector can be turned on and off.

1. Issue One:

Cannot seem to re-connect to printer after shut-down or prompting RasPi to restart from nanodlp interface.  It will also not reconnect after manually power on/off.  Originally and during testing this week I was able to shut down, restart, and reconnect just fine.

Checked the network, and it does not show as device. Tried the address, no go.  reboot of computer, router, RasPi no go.  Checked wires cables all new, no go.

2. Issue Two: (this one is more trouble and worrisome)

After slicing and sending plate to printer, there are no triggered issues or errors logged.   

When asked to print: 

2a: shutter stays closed (double checked after this print and the shutter commands work the servo just fine.  I have selected the shutter to open and close before each layer) so I'm not sure where this is coming from but I am assuming this will be easy to correct.

2b: The more worrisome and troubling error is that only one axis moves (the one without the end-stop).  I had this issue on the original set-up before I reloaded everything. At first I thought it was the end stop or something wrong I did on the first install, but this is the second time it has done this.  So maybe I am just extremely consistent with the error I am performing.  I tried re-calibrated all axes, slicer and printing profiles.  I tested it in the z-axis calibration and both motors work fine, no issues.   

2c. I did get the printer to connect one other time after this print fail, but I cannot re initialize the motors.  I tried home, on/off power, home, on\off then manual move, then on and home - nothing.

[mUVe 3D Admin]

Elliot,

1. This is appropriate for a shutdown. It's just like a PC with no power button. You need to pull power and reinstall it to reboot the system after power down. Or you have to enable HDMI device control on the Pi, then when you turn the projector on it will turn the Pi back on. Those are your only options other than just not shutting down. The issue after updating we're not sure, that would be worth reporting on the nanoDLP forum.

2a. Hard to say unless we see all your settings so that we can ensure they're correctly setup as well as knowing how your shutter is connected.

2b. I'm not sure what you're saying here. The first sentence says only one axis moves. The last sentence says they both move fine.

2c. It's unsure what's happening here. It sounds more and more like a short circuit on your enstop and/or a nanoDLP config error.

What point are you at right now? Can you connect to nanoDLP? Can you home the printer? There seems to be some conflicting information here so it's really not clear what you're trying to do and what is working and what is not. Perhaps you can provide some clarification. Some screenshots of your current settings would also be very helpful. Also what is displayed on the Terminal screen of nanoDLP just after you reboot the whole system?

mUVe 3D Support

[Elliot McAllister]

Hi All-

Sorry for the delay in getting these images as requested, and I appreciate the help in diagnosing the issues.

So to clarify:

Sometimes cannot see the dlp printer in my network UPnP does not seem to find it - However I can link to the site via web, and it is listed via my router home screen that it is active and on the network.   I added it's own static IP.   I believe I still have a connectivity issue and this is the  weird part:

I can log into it via the IP address and work the projector on/off, and the shutter on/off. 

I still cannot re-home the axes no  matter what I do.  I have started and re-booted several times.  triggered home axis as well as motor on motor off.

If attempt is made to turn on/off or reboot RasPi from the nanodlp interface, error message that printer is not connected comes up.

 I have included screen shots here of the set-up.  

[Elliot McAllister]

I will add to that I manually checked the connections to the motors, and end stop position locations.  

[Elliot McAllister]

Hey Matt,

I had seen a link where you documented how you set your printer up, on git...?, but i didn't set a link for it, would you send that over when you get a chance?

[Matthew Caron]

Here you go.

If you have any questions, ask. It's likely that I didn't document something somewhere along the way.

[Elliot McAllister]

THANKS!

[Elliot McAllister]

I cannot connect to the printer on a regular basis, and even when I can "connect" I think I can only get to the web page.  I don't have control other than shutter and projector on/off.  If I try "reboot RasPi or shut down/restart printer I get a connection error message and then I can't get back to the web page.

I cannot home the printer and cannot activate the motors - I believe this is the connectivity issue from above.

[Matthew Caron]

This sounds like a networking issue. Remind me again how your RPi is connected to your network?

[mUVe 3D Admin]

Elliot,

Try changing your "3D Printer Board" "USB/Serial Port Path" to:

/dev/ttyACM1

reboot and then browse to the terminal screen. If it's properly connected via USB it should be numbered 0,1, 2 etc. If you've unplugged and chosen a different port more than once it might have changed to a different number. No sense in trying to home the printer until the system is recognized and you see some sort of output on the terminal screen.

In reference to your other issues, are you using wired or wireless networking? Wireless is super unreliable and only recommended if you're not having problems. Which it seems you are. Not all networks are setup for UPnP and not all older routers are going to support modern UPnP. So possibly an issue there?

The fact that you can only sometimes connect to the nanoDLP 3D printer software on your network makes it seem like you have power issues. Does the Raspberry Pi act funny after you move the shutter? Does the red light blink on the Pi when you move the shutter? If yet to either of those then that's likely causing all the wonkiness. These systems are super stable unless they don't have stable power. Some servos need a lot of power, too much for the supplies given to them.

Another option is to remove the servo power from the RPi entirely and power it via it's own separate power source. Just the signal wire is attached to the pi in this case, which would be the white or yellow wire depending on the manufacturer.

mUVe 3D Support

[Elliot McAllister]

Hi Matt,

I agree, I think this is a set-up network issue.  The Ras Pi has it's own IP static, and is hardwired to the router.

[Elliot McAllister]

Hi, thanks.  I will check the power issue shortly.  

As I'm new to Ras Pi and Linux I didn't go through all the localization or ssh set up that Matt completed on his.  I am adding these and then the Nano back on top.

I do have the Servo wired for power off the RAMPS and the signal from the RasPi - this seems to work brilliantly.  I think it's the connectivity - and I fudged something on how the Pi recognizes and boots up with the net work.

So far here is what I have completed:

change log in password and new hostname/Icarus

sudo raspi-config

-Expand File System- Allowed 4Gb of 60 for OS.

-Loginpassword

-boot - boot to command line

-Wait for network at Boot (Y)

-Interationalization: 

-Change Locale: (en.US_UTF-8 removed en.GB_UTF-8) 

-Change Time-zone (self explanitory), 

-Keyboard Layout (en.US_UTF-8)

-AltGr key is dual icon keystroke

-ComposeKey= Ctrl+period 

-Advanced Options:

-Overscan: (Y) Black lines on outside of monitor - not sure if this will have an affect on nanoDLP

-Hostname:

-Memorysplit: Allowed 4 GB for OS, of 60 total

-SSH: (Y)

-Device Tree: (Y)

 (not sure on the rest of these so leaving alone:)

-SPI, I2C, Serial, Audio (should not control anything - HDMI port for Audio), GL Driver - Please let me know if there is anything else or something I am incorrect on!

Rebooted:

added user as per Matt's documents:  But I have a question on the copy keys to authorized_keys.  I am not sure what/how this works.  Do I need to know the IP address of the RasPi:

ie: ssh-copy-id us...@123.45.56.78

is this: ssh-copy-"myname"@ser.ver.ip.ad ?

 

[Elliot McAllister]

It's hardwired to the network, new router Linksys AC6200.  Static IP reserved.

[Elliot McAllister]

Hi Admin-

I will try the different address - currently I started a reinstall and adding PuTTY for -ssh.  ( I am extremely new as in this is my first Linux experience) so this is taking me a bit of time to research and understand what I'm doing. (Originally the reason for not installing this was that I had no idea the keyboard could be re-programmed - but thank's to Matt's write up I figured this out!)

It is a hardwired network to a new Linksys Router AC6200, Static IP reserved.

Power could be, it wouldn't be the first time.  It could also be the split cord to connect Arduino through the computer wall.  I will try to run straight through.  I do have the power for servo off the Arduino and the signal to switch from the Pi - so no power drawn from it.

I need to add from Matt's write up to make sure I get all the Pi communication ready.  If someone has a direct set of entries for the code that would be great (or even just an amended set from Matt's)  I've been able to follow that very well with only a few questions remaining.  (Basically from the add user and mod user I do not understand what I am doing codewise - I understand the need for -ssh keygen.)  I'm hoping I can move the order of when this was done in Matts and not mess up anything.

[Matthew Caron]

Hi Eliot,

Sorry for not responding sooner, as I've been ill (food poisoning? Flu? Something like that. Very unpleasant).

Anyway:

 1. Creating a new user is not strictly necessary. I do it because I have a script set up to ssh into all the machines in my house and apply updates - but this script is predicated on doing it all as me.

 2. The ssh key stuff is for security. Key-based auth is harder to break into than password-based auth. This is standard procedure for all of my machines, but is not strictly necessary.

If it's hardwired with a dedicated network connection, I'd think it would be fine networkologically speaking.

Here's a couple of thoughts:
1. Can you post a screenshot of what it looks like when you lose connection with the RPi?

2. Can you reproduce this pretty readily? If so, you can run a "ping" and let it run constantly (I want to say it's ping -i under Windows, but I don't know for certain). Let it run and if it keeps going when the RPi goes away, then NanoDLP is crashing, not the RPi.

3. You can also SSH into the RPi and do "uptime" which will tell you how long it has been since it last booted. If it's only been up 2 minutes and was supposed to be up 10, then it's rebooted itself. Otherwise, it's something else...

[Elliot McAllister]

Thanks Matt, and I hope you feel better!

OK, So I  have -ssh set up and have been able with the keyboard to follow your instructions to dl the nanodlp.  I'm now up and running.  I did get one error - possibly while completing this step attached in a screen shot.  It does not seem to have bothered the remainder of the set-up.  After rebooting both the RasPi and the Computer, I have the DLP under UPnP and it pulls up the screen.

Again, going to the distro change either by button or through manual input will result in error code: this site cannot be reached 192.168.x.xxx refused to connect.  ERR_CONNECTION_REFUSED

checking uptime on pi: 

2 min...but it should be longer - could it be rebooting because of the new distro?

Seems to have worked.  I can still connect through PuTTY or through the IP.

So this seems to have solved the connectivity issue.

Now, after setting up again,  I still have an issue with the z axis, but other controls are still good.

This would appear to be a loose connection or mis-wiring, possible endstop.

I tried to change the arduino address as suggested by Admin, the original address seems to have been correct.

Here is where it's a little tricky.

I cannot via printer controls turn on or off the z axis motors.  I tried hard wiring direct from the Pi to the Arduino, but that didn't change it.

If I only connect the ramps, no usb, and turn on the power, then the motor on one side pulses 2x, the green led lights up 2x.  Then all power to the motor stops.

So I double checked the connections to RAMPS and the routing.  It is correct.  I double checked the endstop, that seems correct too.  

But this seems like an endstop or signal issue from RAMPS to the motors.  Can anyone tell me what the voltage readings should be:

endstop, at enganged, at disengaged

Motor voltage: This is variable - is there a general operating voltage?

Thanks!

[Matthew Caron]

I get that error too. It's a bug in the script, but otherwise things seem to work.

The distro change causes a reboot. So, you will get a temporary connection error, then it will come back. This is normal.

When you say "hard wiring the Pi to the Arduino", what do you mean here? Like, there are no other options - you connect it with a USB cable. How is that not hard wired?

The motor should not move when you turn on the Arduino with no USB connected. If it does, I think maybe your firmware is wrong. What firmware is loaded into the arduino?

Which endstop are you using, BTW? I don't recall, and don't see it above (but I did look through it quickly)? Remember, the prewired one is inverted and you need to fix up the firmware accordingly.

[Elliot McAllister]

OK: 

The firmware from git hub: https://github.com/mUVe3D/Marlin-mUVe1DLP-Running

I still have no z-axis movement.

I power up arduino first followed by RasPi,  I have putty connection and can find easily the printer.

I have attached the images of the board hook ups.

Note; fan connection is removed.

[Elliot McAllister]

I have a steady red from Pi, some blips of green

Arduino has flashing orange, can't tell where it's from, RAMPS covers it.

[Elliot McAllister]

ok how do I fix the firmware for the pre-wired endstop?  This could be it, since I ordered the pre-built one.

[Elliot McAllister]

OK found the note in the read me file (duh)

Looks like I fried the Mega.  blinking lights TX RX when plugged in, green steady power light.  But the USB won't recognize the connection - no device manager errors.  I tried a few different versions of the IDE as well as different cables known to be good.  Ordering a new board.  This would seem to be the issue

[Elliot McAllister]

Update: 

New Arduino Mega board, loaded firmware all seemed fine.  (Old arduino board would not be recognized)

1. Connected via Pi, hardwired. No issues

2. Boot-up Pi then Arduino/RAMPS

3. Connection thorugh desktop shortcut (all fine)

4.  Home printer - Fine

5. printer Calibration - turn projector on, fine

6. shutter open then close fine

6. projector off - no

7. move axis up to "top" - no

8. motors off the on

9. move axis up - no

10 reboot

11 home axis - only one motor turns (non-endstop)

12 motors off/on

13 home - only one motor runs - check motors only left had motor is on.

14 power down and reboot.

15 reboot and connect - fine

16 home axis - all motors work and homes fine

17. move up 100, fine

18 move up 50 - no movement

19 move up 10 - moves DOWN 10

20 move down 10 - moves DOWN 10

21 move down 10 - moves DOWN 10

22 Home - fine

23 move up 50 - fine

22 move up 50 - no movement

23 move up 100 - fine

22 move up 50 - MOVES DOWN 50

23 home - fine

24 move up 50 - fine

35 move up 50 - no

26 move up 100 - fine

27 move down 10 - fine

28 move up 10 - moves DOWN 10!

29 move up 50 - moves DOWN 50!

This is all from the z-axis calibration screen.  I had noted that top was bottom on the previous runs, but this is really eratic!

[mUVe 3D Admin]

Elliot,

We need to know everything about your set to help. We're missing a few very important details.

-What version of nanoDLP are you using?

-What endstop are you using?

-What firmware did you use?

-How did you configure the firmware?

Unless we know for sure that you did all of this without errors, and that your wiring is setup properly to match, you could get all kinds of erratic issues. Perhaps your motors are plugged in backward?

Notes:

The "TOP" Button in nanoDLP is/was originally for Raspi connected motor drivers, not USB serial connected systems. So perhaps by using that button it created an odd nanoDLP positioning error? It's now possible to define what the "TOP" and "BOTTOM" are in nanoDLP but we haven't had a chance to verify these new features work. So if you decide to try them be sure to proceed with caution. Otherwise you need to avoid using these buttons until their placeholders have been filled in.

Everything you explain with the motion commands won't tell us much unless you also go to the terminal screen in nanoDLP and see what code was sent to the RAMPS board when you pressed that particular button. So if you're pressing Z+ 50 and it goes down by 50 instead, your first response should be to check the terminal screen and see what was actually sent to the printer. Chances are there's an issue with nanoDLP or you have a misconfiguration and it's causing a positioning error.

Lastly, when the axis moves up and down instead of just up like you're explaining. You've likely got the configuration in relative positioning mode instead of absolute or vice versa. Everything must match, the firmware, nanoDLP, the profiles in nanoDLP, and the settings in nanoDLP. Without the entire setup being appropriate it can't be expected to work. Be sure you're following the instructions and that you're using the latest profiles and firmwares, if you can 100% ensure those things then you're on the right track.

mUVe 3D Support

[Elliot McAllister]

Hey all- 

Here are the answers to the questions:

1. Downloaded the latest version as per the set-up instructions for nanoDLP

2. Unknown endstop - it was soldered when arrived, however this is from the pre-built order so it was soldered upon arrival.  (Double checked the plug in was not backwards)

3. Marlin v_1 firmware, but do I need to re-install the new configuration.h (from the endstop question)

4. Firmware was installed to RasPi, distro change to muve, set-up as per instructions on site.

5. Double checked the motors - they are as per images in 1.5 DLP build pictures.  Interesting that they move up on the first up command, then reverse.  I double checked that the GCODE was asking for relative not absolute positioning.

I did check the terminal to determine the Gcodes.

here is the output:

minal

M280 P2 S2500

start echo:Marlin 1.0.0 echo: Last Updated: May 2 2016 13:13:57 | Author: (none, default config) Compiled: May 2 2016 echo: Free Memory: 4983 PlannerBufferBytes: 1312 echo:Hardcoded Default Settings Loaded echo:Steps per unit: echo: M92 X36.36 Y36.36 Z400.00 E400.00 echo:Maximum feedrates (mm/s): echo: M203 X600.00 Y600.00 Z20.00 E20.00 echo:Maximum Acceleration (mm/s2): echo: M201 X4000 Y4000 Z4 E4 echo:Acceleration: S=acceleration, T=retract acceleration echo: M204 S3000.00 T3000.00 echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s) echo: M205 S0.00 T0.00 B20000 X40.00 Z0.40 E0.40 echo:Home offset (mm): echo: M206 X0.00 Y0.00 Z0.00 echo:PID settings: echo: M301 P22.20 I1.08 D114.00

G90

ok

G28 G90

ok ok

G1 Z1.00

ok Z_move_comp

G1 Z10.00

ok Z_move_comp

G1 Z50.00

ok Z_move_comp

G1 Z100.00

ok Z_move_comp

G1 Z-50.00

ok Z_move_comp

So all these moves should be comparative to the current position.  The printer followed the proper course on the up moves.  When asked to move down -50, it dropped to the bottom like it was re-homing.

So I manually entered Gcode, starting with use absolute measurements, manual entries for 10 consecutive moves go without fail.  I'm wondering if I need to reconfigure the buttons as suggested above - but it's weird- the original install prior to connectivity the buttons appeared to work fine.  

I'll try to do a slice and print while watching it maybe it's just the buttons.

[Elliot McAllister]

OK, so I wrote a little code for the machine to follow, all went smoothly from the terminal except for the pause/dwell time which I think is most likely my syntax or the pause time was eaten up during the movement since I didn't put in a respond command.