Locomotive Elevator

@inq I'll get in before someone else does, have you had a look on that Chinese web site? I have and there not there.

Just found this

This is a slightly different variation of what I am trying to build including a computer controlled system to operate it using another train control type of software called Train Controller, if my works to this level of accuracy I will be very happy.

This goes with it as well

Cheers Phil

@davee I will continue to use store bought level shifters and if I ever have a problem I will get your assistance. I have bookmarked your post.

@thephilnewman But Loklift is Selectrix bus which you said you want no part of.

@zander What I said is its not compatible with anything else on the market so its of no use at all to me, its an obsolete system no one uses it any longer

cheers Phil

@thephilnewman I know, that's why I was confused by your post showing that system in action.

@thephilnewman 

As was suggested earlier it might be that one driver was using microstepping to divide one full step into smaller microsteps. The quieter version seems to be a tad slower?

I was surprised to see the use of two stepper motors, particularly as it is not lifting a whole shelf the way you intend doing. What if one failed or got out of step. I thought a single stepper would have been sufficient with two guide rails on either side of the platform.

@zander I can see no reference to Selectrix here?

https://github.com/aikopras/Lift_Vitrine

Cheers Phil

@thephilnewman Agreed, I saw it in the iTrain 5 manual.

@thephilnewman That one at a minimum uses 3 ArduinoMega's and a NANO plus supporting custom PCB's. Is this what you plan to use?

How will @Inq's system fit into this?

@thephilnewman One key point, in that video, a single section is moved (with 3 tracks). To me that seems much more manageable and still accommodates the storage of a huge number of trains.

@thephilnewman One key point, in that video, a single section is moved (with 3 tracks). To me that seems much more manageable and still accommodates the storage of a huge number of trains.

@davee Hello, any chance you could have a look at the drawing I have done, just to let me know if its all okay, my perf board and other bits turned up today and I started putting them on the board and started soldering, a couple of hours later I ran out of room on the board, doh!! So I thought I had better do a drawing of how it needs to be before I waste another load of stuff!! What I am trying to do is put the control circuit for both stepper motors on one board, also the enable is not being used in @inq code. The main part I was unsure about, or where I got confused was putting the anti bounce capacitors and resistors on the board.

Cheers Phil

Hi @thephilnewman,

  I'll have a look and comment on what I see, though I know that it is very easy to miss something. Usually it is possible to do minor changes to prototype boards, but try to make it so the parts and solder joints are still accessible, since it is likely something will show up.

-----------------

Personally, I know most people wire up a board, and then start testing, but I would mentally divide the board into electrical sections. I would construct each section and then do a simple test or two, on that section before starting on the next one. That way, mistakes tend to be found earlier, when they are easier to fix.

Given the number of pins that can stop the ESP8266 booting by being high or low, I think I would start with the ESP8266, check it boots etc, both with USB power, and with 5V external power. Then gradually add the other connections, regularly checking to ensure it can still boot, plus 'read' the input, if it is a limit switch, or switch the transistor if it is an output. This way, if it stops booting or not behaving as you expect, only a small number of connections, etc. are likely to be the culprit. (Obviously, you disconnect the power whilst adding new connections.)

Comments

The Enable- resistors are not connected to the ESP8266. I realise that they are not 'essential' to be driven, and if you use DM860H Enable as an emergency stop, then maybe it will not be driven by the ESP8266, so there are some implicit decisions as to what should be wired now. I had thought about wiring the ESP8266 pins, but leaving the flying leads to the DM860H off .. but this is a question of taste. 

I discuss ESP8266 connections for this in terms of ESP8266 pin allocations, even though they might not be connected yet.

----

A point of 'style' .. if two lines cross without a 'blob' at the connection, that is normally interpreted as not connected. And because 'blobs' are easy to miss, they are frowned  upon. Thus when you have 4 wires, which are connected, they are normally converted to two 'T' junctions slightly displaced from each other.

On your drawing, the Gnd wires a little to the left of the ESP8266 just cross, but they should be connected.

--------

Another 'style' point. The USB connections are +5V and 0V. Writing +5V and -5V implies that the voltage between those two points is 10V.

---------

If you are mounting the ESP8266 on the same board, have a think whether you want connections to any other pins.

For me, an obvious one might be more accessible push switches for Reset and Flash.

--------

Whilst you are showing the drive connections from the ESP8266 to the DM860H, I am not clear how the ESP8266 is being commanded. Is this all by WiFi?

--------

Have you checked that each of the ESP8266 pins you have chosen doesn't have any dark secrets that mean it would be good to pick another one?

I haven't used this board, so can only rely on the web for some guidance.

First guide I found was from RND who are usually reliable, at https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

I am listing the pins you have connected, including D8, which I am suggesting (NB please check for errors.. don't believe my script):

D0 - GPIO16 -- L Dir drive      -  high at Boot, should be fine, providing no Pulses at boot

D1 - GPIO5  -- L Pulse drive    - OK

D2 - GPIO4  -- L Limit Input    - OK

   Not allocated   -- L ENA drive     - D3 GPIO 0 and D4 GPIO 2 are candidates, but might need care to ensure transistor does not pull it low at boot Also D4 connected to onboard LED. See discussion below.

D5 - GPIO14 -- R Limit switch  - OK

D6 - GPIO12 -- R Dir Drive      - OK

D7 - GPIO13 -- R Pulse Drive   - OK

D8 - GPIO 15 -- R ENA drive   - Think it is OK as an output ... Transistor should not pull it high at boot

-------

I confess this is the first time I have looked at this chip ... and at first glance it seems to have lots of "won't boot if that pin is high or low" rules that I hadn't expected.

It's late, and my grey cell is not really awake, but I think the only problem is finding a good pin for the Left ENA drive pin. D3 is the "obvious" choice, but I am worried that at boot, the extra transistor/resistor will drag its voltage down, and the chip will refuse to boot.

I think a work around would be to change R1 to say 10k Ohms, and add a 1 kOhm resistor between ESP8266 D3 pin and an ESP8266 3V3 output pin. This extra resistor will ensure the pin is high when boot starts, but the program will change the pin to an output, and it can then push it high or low under program control.

---------

I was going to suggest an alternate strategy would be to move the R Limit switch to RX GPIO3, thus freeing D5 - GPIO 14 for R ENA drive. But I have just looked at the schematic, and GPIO3 is effectively connected to the USB data lines (via another chip) ... so that is a non starter!

--------

Clearly the R ENA connection in particular will need a little testing .. for now the easiest might be to leave space to add the resistors at a later date, or maybe put the resistors in now, but make sure you can change them later if something weird shows up.

--------

Sorry, this is not quite as clean as I would like it to be.

Best wishes and good luck, Dave

New InqPortal 5.4.0 library and new TrainElevator.ino 0.9.6

@thephilnewman, @zander, et al

Me living through Phil's troubles trying to apply the InqPortal patch on a Mac was the serious motivator for me to dig-in and determine what had changed.  Sorry for the abuse Phil! 🙄 Another catalyst was the constant nag of the Arduino IDE 2.1.X to update the ESP8266 Boards library.  I was pretty immune since the old IDE 1.8.19 that I use lets me turn off that nag.

Most of the changes were because of a newer version of the GNU C++ compiler used by Espressif.  It is more particular about the way I wrote some things.  Espressif (the chip manufacturer and low level software company) also changed their API.  Actually they changed it a couple years ago, but the open source group that makes the Arduino IDE version only got around to using the latest Espressif version a few months back.  I think @zander and @zonnycom found it.

Anyhow... InqPortal has been updated to 5.4.0.  This update has no new features, but simply permits the latest version of the ESP8266 Boards library 3.1.X to be used.  No more nagging.  It also no longer requires the Patch!  One API related to DHCP had been deprecated, there is no replacement.  Even without it, I've not seen any ramifications in my testing.  Please let me know if you run into any bad behavior.  I've also updated and streamlined the development environment installation instructions https://inqonthat.com/arduino-ide-configuration-for-windows/ and removed all references throughout the website about the patching.  5.4.0 is now available on the Arduino IDE library manager and will nag you to upgrade if you use the 2.1.x IDE. 🤣

TrainElevator.ino 0.9.6

This had to be upgraded only because of the newer, more particular GNU C++ compiler.