UPDATE 6-21-2019 - I had a problem shortly after applying this config, where I could not log into the router after a power cycle, but seems it was just a transient problem.  I swapped the AC1900 for a spare at the time, until I had to to look into it.  I reverted back to the AC1900 today, with the VPN config described below, and all is well (without making any changes), so whatever the problem was, does not seem to have anything to do with the changes I made to the VPN stuff.

I recently found how to get a VPN client (using a VPN provider), and OpenVPN server running on an Asus 1900 (same as the AC-68U) running Merlin firmware.

Without making some changes to the config, the OpenVPN server will not be accessible by an OpenVPN client on a smartphone or other device when also running an VPN Client on the same router (Asus 1900 in this case).  I got it working and here is how:

First I set up the VPN server using OpenVPN, and tested that it worked with an OpenVPN client on a phone.  Then I turned the OpenVPN server off (on the router), saved and rebooted the router.

Next I set up a VPN client on the router, using a VPN provider, and tested that it worked.  Verified that it was directing all traffic to the VPN by going to google and searching for "what is my IP" - it was the same IP as what the VPN client on the router said it would be (and not the IP from my ISP).

Next, with the VPN client running on the router, I enabled the OpenVPN server on the router which I previously set up and tested.  With both the VPN client and OpenVPN server both running on the router, I confirmed it did not work when trying to connect from an OpenVPN client on a phone (making sure to have wi-fi off when testing since it will always fail if connecting from the LAN side of the router).  This was not unexpected since the OpenVPN server on the router would be seeing the client (on the phone) traffic from the WAN port, but would be sending it back to the phone via the VPN Client through the VPN provider (so the source IP of the returned traffic from router -> phone would not match what was sent from phone-> router).

Anyway, trust a random person on teh Internets that it will not work, without some giggling of the config (and note, I am not an expert on this).  After some poking around I found out how to do it using policy based routing (found in the VPN Client config of the router).  Note that it was a bit buggy at first, and when I ran into weirdness, like having just the LAN block set to route to the VPN, but google still showing my ISP's IP when searching "what is my IP".  I found that even though a working config was "saved", the router needed a kick in the pants to actually clear out the cruft and start working as configured (so keep that in mind if it looks right but ain't werk'n right).

To git it werk'n...

First, for reference, say the router uses 192.168.1.0/24 for the LAN, with the router being 192.168.1.1 and the rest of the devices on the LAN using 192.168.1.2 through 192.168.1.254.  That is pretty typical for most home setups.  When adding an OpenVPN server setup on the Asus (using Merlin Firmware), the VPN traffic will get a different block, and that defaults to 10.8.0.0/24 (or 10.8.0.1 through 10.8.0.254).  This means that when I connect to the Asus router from an OpenVPN client on the phone, the phone is assigned an IP of say 10.8.0.3 by the Asus router. 

Pardon my crudely blocked out configs, but those are unrealted to this anyway.  The below pic is from the the VPN Client config and shows the VPN subnet:

So I figured that for starters, for the OpenVPN server to work while the VPN client is connected to a VPN provider, I would need to send any traffic from the Asus router back to the OpenVPN client on the phone via the WAN port on the router, and not via the VPN provider.  So I used the policy based routing configuration under the VPN CLIENT config on the router (note it is not called "policy based routing" but I will explain).  To enable policy based routing, I set the following under the VPN Client config:

Redirect Internet Traffic > Policy Rules Strict

That will then allow editing of the "Rules for routing client traffic through the tunnel".  In this section I did the following (see the pic below):

1.  Send all traffic from 192.168.1.0/24 (the LAN), to any destination (which is defined as "0.0.0.0" on the router's config), to the VPN provider.
2.  Send the traffic from the router itself (192.168.1.1 is the Router's LAN IP), going to any destination ("0.0.0.0"), to the WAN port.  This is needed so the VPN client on the phone will make the connection to the router, and the router will send that traffic back to the phone via the WAN.  So the OpenVPN client on the phone connects to the router on the WAN port, and the router responds to the OpenVPN client on the phone from the WAN port.

So that got me 50% the way there.  I had the OpenVPN server running on the router, along with the router's VPN client connected to a VPN provider, the phone connected using an OpenVPN client (when not connected to Wi-Fi),.  And I could see that the other LAN traffic was going to the VPN provider since when I went to another PC on the LAN and searched google for "what is my IP", it returned the VPN provider's IP and not the ISP assigned IP.  

However the reason for using the OpenVPN server on the router in the first place is to access devices on the LAN remotely and securely, without opening ports on the router.  In this case, the need was to access security cameras remotely.

With the current setup, although the OpenVPN client could connect to the router's OpenVPN server, the security cameras could not be accessed using the phone.  So here is what fixed that - again in the VPN Client config's "Rules for routing client traffic through the tunnel":

3. Send the security camera traffic (which are in the 192.168.1.x range since they are on the LAN), to any destination which is in the IP block used by the OpenVPN server ("10.8.0.0/24"), via the WAN port (not the VPN).

Once I added all the cameras to the "Rules for routing client traffic through the tunnel" as seen in the pic below, I was able to both connect the phone's OpenVPN client, and then connect to the cameras remotely though the VPN (using their 192.168.1.x addresses on the phone).  Note that it was OK to have a rule directing all traffic on 192.168.1.0/24 (which is any IP's on the LAN) to the VPN provider, and then having another rule for a single IP, say 192.168.1.200 going to the WAN instead.  It just means that 192.168.1.1 through 192.168.1.199, and 192.168.1.201 through 192.168.1.254 will go to the VPN and 192.168.1.200 will go to the WAN (as an example).

Note, these are just the configs that got it working, and there may be a better way.  Also the other rules not related to this, such as "Block routed clients if tunnel goes down" need to be determined based on how the VPN is being used and have nothing to do with getting the other stuff working.

I still need to figure out how to best keep outlook mail from having a fit when it sees a client connecting from a VPN provider's IP space.  Ideally, SMTP/POP/IMAP could be shunted to the WAN, but there is no easy way to do that currently from the Merlin GUI (that I know of).  Getting into the weeds of maintaining it using scripts may be the only way. 

In the mean time I kludged together some more "policy routes" to send any LAN traffic that should go to gmail or live.com email servers, to the WAN.  To determine the servers IP's, I looked at the email configs and then use the "nslookup" tool which can be run from a command line in windows.  I then used these IP's and set up policy routes similar to the above, like this:

Source IP (192.168.1.0/24) -- Destination IP ("email server IP") --- Iface (WAN)

I have more than a dozen of these entries now between live.com and gmail email servers, but it seems to be working (no longer seeing that M$FT is locking the email accounts out when the VPN Client is enabled.  There is a list of Gmail netblocks here, but likely not all of them will be used (but if there are problems I would probably just add them all until it could be figured out).  I also set up a few other devices to use the WAN exclusively (so they will never use the VPN).

There is a workaround for setting policy routes for every damn provider that blocks VPN's however - and that is dedicated (residential) IP  VPN's which cost a bit more but can bypass some of this stupidity. 

Update 5-15-2020 Also one more update for running the VPN server on the router.  The router can generate a client configuration, but I had some problems with the autogenerated one which did not include the client key.  It has been a while since I did this, but I recall that I had to generate the CA, client and server keys and certs, as well as the DF parameters and then I set those on the router (server) and also edited the client.ovpn file manually to get it working.  A similar process is described here and here. 

There is another less secure way to get the VPN working detailed here, which basically negates the need for a client cert and only uses a user/pass for authentication (by setting Username / Password Auth. Only" = yes in advance settings, and then regenerating the VPN client config from the router).  At that point the generated file will only have the "<ca>" section and will not have any client cert or keys present (.  I did not try that but I read that it works, but is less secure. 

Let the smoke out of the battery but fortunately no fire.  Won't be using this cell anymore though, which sucks since it was brand new, just out of the package.  I think the crimp on the positive terminal of the battery holder has a rough spot which cut the insulation and shorted out to the case of the cell.  Now I have to go back and redesign the battery holder for my 90mm Solder Fume Extractor, once I find a better holder (sucks).

UPDATE 6/19/2019 - Not digging the auto leveling on a Delta (works great on a Cartesian though).  The trade offs with an offset probe on a circular bed seems to cause some problems for my setup.  Right now I just want to get it working so am gonna revert to a removable zero offset probe.  Will leave this stuff here though since it can apply to a Cartesian printer or folks that want to try it on a delta.

This post is updated on 6/12/2019.

I want to add a 3D Touch probe to my Re-ARM board.  There are two things that I think need to be done differently than a regular RAMPS setup with a BL-Touch however.  The first is that the the normal pin that would be used for the probe is Servo 0 (D11) does not have a 5v level shifted output on the Re-ARM (at least as far as I could find).

However, Servo 3 (Pin D4) does have a 5V level shifted output according to the docs.  The probe may work with 3.3V out, I'm not sure, but I would rather just use a servo pin that can send 5V to reliably trigger the BL Touch. 

The second problem is that the 3D touch was not reliable when I tested it with the onboard 5V from the Re-ARM as shown below.  It seemed that the coil would energize and hold the magnet on the probe, but then it would drop it, and I noticed that the display LDC backlight would dim when the probe was operating.

I've read that adding a 5V linear regulator like an LM7805 has helped with this problem on RAMPS 1.4 boards, and there was a simple mod for that.  However on the RAMPS 1.6 board I am using, there is no jumper for the Servo 5V power rail (it appears to be just connected to the onboard 5V regulator).  I plan to add an external 5V regulator which will run off the same 12V supply as the rest of the printer, and supply the 3D Touch probe, but waiting on parts for that.  (UPDATE the 5v external regulator works fine).  My WT-LC case has a place for mounting something like this behind the board, so I made a small mount for it which will put the regulator between the fan and Re-ARM + RAMPS (you can find it at thingiverse).

Something else that I added and is not shown in the pic above, is a 10KOhm resistor across the black and white wires (which go to the Z-min endstop on the RAMPS).  They provided the 10KOhm resistor with my 3D Touch probe, but there were no instructions that I could find to describe what it was for.  I found a discussion about it which inferred it would be used the same way as the resistor on the BLTouch which has a 640ohm resistor for this purpose.  Adding the resistor seemed to help a bit with the stability of the connection, just wish it was better documented.

The last thing which has been a problem for me, is understanding the way the servos are numbered in Marlin.  They start at zero and go to three:

I needed to add the following to get Marlin to compile (this config works OK with my setup - which is a modified Anycubic Kossel Linear Plus) - NOTE I AM USING SERVO 3 FOR THE PROBE (D4 on the Re-ARM).

Note that SERVO_DELAY had to be added, and also had to be an "array" with the same number of elements as the number of servos.  The way I read it is like this:

#define SERVO_DELAY { SERVO_0_DELAY, SERVO_1_DELAY, SERVO_2_DELAY, SERVO_3_DELAY }

There was no "NUM_SERVOS" defined in my config, I guess that it figures that out on it's own based on the "PROBE_SERVO_NR 3".  There seems to be several entries that have been depreciated or changes since I last set up Marlin using Atom.

The "BLTOUCH_DELAY 750" was changed due to a suggestion I found in the marlin forums.  I also set the value of 750 in the "SERVO_DELAY" to keep it consistent (hopefully).

Once I get this all tested I will update this post with what was done, and some pics of the setup. UPDATE - this is tested and the probe works, the problem I now have is with the probe hitting the bed clamps since it is an offset probe on a delta printer.

I wanted to update Marlin so I would add a 3D Touch probe to my Delta printer, but was having nothing but problems with Atom + Platform IO.  I uninstalled, reinstalled Atom and Python, cleared the files in the /Users/Username/ and /Users/Username/AppData/Local directories for Atom and Platform IO, but had no luck.  Then I read that platform IO recommends VSCode.  I also read somewhere that VSCode does not have the CLANG requirement which is cool since I was never able to get that to work anyway.

So I went and downloaded VSCode and had some issues, but was able to get it working.  I did not keep good notes on what I did, but some things that helped were:

Installed VSCode
Installed Python 2 and 3
Installed Git

Installed PlatformIO IDE and Autobuild using the instructions here.

I also found that I had some additional problems with the path, some of these were automatically added, but below is what is in my $PATH (I have other stuff but these are what are probably relevant to getting this working):

C:\Users\USERNAME\AppData\Local\Programs\Python\Python37-32\
C:\Users\USERNAME\AppData\Local\Programs\Python\Python37-32\Scripts\
C:\Users\USERNAME\AppData\Local\Programs\Microsoft VS Code\bin
C:\Users\USERNAME\.platformio\python27
C:\Users\USERNAME\.platformio\python27\Scripts

It may also be necessary to disable the antivirus when installing platformIO IDE.  Otherwise it may not be able to download the necessary components.

When running a test to compile Marlin I also had to click the "bell" at the bottom right and agree to allow VSCode to do something it needed to do (summarizing).  I can't recall where I found this mentioned, but it was not something I found.

Finally, like Atom, I needed to RUN VSCODE AS ADMINISTRATOR.

The platformio.ini file also needs to be updated if using a different board (like the Re-Arm).  That is the same as in a prior post here.  To test however, which is a good idea to make sure vscode will compile at all, no changes should be made to configuration.h, configuration_adv.h or platformio.ini, it should just compile out of the box.

To update platformio.ini for a Re-ARM, in a nutshell, this needs to be done:

change the following in platformio.ini:

env_default = LPC1768

and then add this in the section under "[env:LPC1768]" (does not matter where):

upload_port = /Volumes/REARM


Then the board and other stuff that is relevant needs to be updated in configuration.h (not covering that here since it would take WAAAY too long.


Something else that may help (and I don't recall where I read this), but I moved the Marlin directory to a shorter path (ex E:\firmware\Marlin-bugfix-2.0.x).

Compiling with VSCode is similar to Atom.  It should be possible to do using the "Autobuild" extension by clikcing the "AB Button" and then clicking the "B", however it errors out for me, seems that something is still looking at /buildroot/share/atom?  I'm still working on this, and will update when it is figured out.

However, I was able to compile using the "check" at the bottom left though:

So at least it is compiling without errors now, but I need to get the 3D Touch probe working with the Re-ARM.  I've not tested the firmware.bin that was created but noticed it is a bit smaller (176KB) than my older firmware (200KB)That will be in another post however.  Update 6/12/2019, the firmware.bin works fine, just copied the firmware.bin from the \.pioenvs\LPC1768 (which is under the Marlin directory), onto the SD card, dropped that in the Re-ARM and it boots up no problem.

It's been helpful for me to add a version to the splash screen so I can confirm what config version I am running, something like this under configuration.h (I will probably also add the marlin build version to the splash screen in the future):

#define CONFIGURATION_H_VERSION 20190612-005

#define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes.
#define SHOW_BOOTSCREEN
#define STRING_SPLASH_LINE1 SHORT_BUILD_VERSION // will be shown during bootup in line 1
#define STRING_SPLASH_LINE2 "v20190612-5" // will be shown during bootup in line 2

I will make another post when I get the 3D touch working.  I have the config which seems to be compiling OK, but am waiting for a part, and then I need to try and get autobuild working.  Update 6/12/2019 - the Z-probe is working, but needed it's own 5v regulator.

This is just a scaled up version of the 60mm fan fume extractor which I never posted since it sucks (not in a good way).  Hopefully this will work better.  Even though it is just scaled up, the internals are fully re-worked so it has taken a few weeks to get things to a point where I think they may work.  Cable management has been a PITA and I am still working on it.  This will also use a 18650 cell so no mod is needed to get the USB battery management module to charge it properly.  It will also work with the Stanley case using the base module which will have a small compartment to hold a USB cable.