The Neoleds are placed in a block so that they can be connected to each other with a bare solder wire. You do not need a PCB. The 3-pin connector is clamped between the 2 wooden pieces and attached to the Fischertechnik plate FT-38251. Here 4 LEDs are placed in a row. The 2 outer LEDs indicate in green that the lift door is open. When the door is closed, the 2 central LEDs are shown in red. All Neoleds are in a string and each LED can have its own colour (24bit RGB). For the string control you only need 5V and only 1 drive pin of the controller. All LEDs fit in a string, I have 120 pieces available.

My lift of the trajectory has 3 double moving doors, which shows the status. Between the LEDs and Fischer Plate there is a white sheet of paper for light distribution + an orange colour filter to reduce the blue light somewhat.As soon as the 3 LED indicators are mounted, I can start to make a video. Then everything will be even clearer. The various routes that are possible will also be shown regularly in a video. But this requires some video editing work!Answers may also be the German language, I do read it.

sorry for abusing your thread for discussing sets.Glad to see that the latest language discussion didn't discourage you.Are you using two LED (two green and two red) for each door for design reasons, or technical?

The Rob hat geschrieben:Are you using two LED (two green and two red) for each door for design reasons, or technical?

Just for design reason. Technically it takes a bit more work, 4 leds have to be changed now when the door moves. The LEDs are on the 15 mm pitch of fischer block. By taking 4 LEDs, the active LEDs are in the centre of the door position. It's much more beautiful and it feels logical as well.

The color of the LEDs have a simple program structure into my FPGA. Each LED can contain 4 predefined 24 bit colors. I use a dual ported ram from the FPGA for this purpose. In addition, each led has a 4 bit mode. The 2 lowest bits select one of the 4 predefined colors, the 2 highest bits have a enable and flashing function. To control a LED, only the 4-bit mode needs to be changed, not the 24 bit color value. The output task reads this 4 bit mode and uses the correct color and function per LED. The program is designed for 128 LEDs. The timing of other program components are not affected by this. Neoleds need very strict timing.

The neo LEDs are now mounted on the elevator together with the 7 segment display at the top that indicates the level and also the direction in ascending or descending. The colours of the LEDs are in reality much more beautiful and accurate. On a photo or video, this can almost never be reproduced correctly. The proportion of blue in the LEDs remains much too high and gives a bad color reproduction along with saturation. The lift has 8 servos, 12 neo leds, one XM-motor, one Rotary encoder, one hall end switch and a dual 7 segment display. Everything can also be controlled via the IR remote control.Here is a picture of the results:

Now I still need to update some FPGA software to let the elevator work completely autonomously with the doors, the neo led status and the 7 segment display. Most of the functions are already working, however, so that should not be a problem.

MasterOfGizmo hat geschrieben:Why do you use an FPGA for this? Looks like an Arduino would also easily be able to do the job. Not that i have anything against FPGAs. But this sounds like a total overkilll ...

This is only one module of the hole super "Kugelbahn" I need 100 inputs/outputs on my FPGA. I have used the the ATxmega-256A3U but it is also far too small. An FPGA gives you all the freedom you need for your input and output signals and functions. This makes the layout very simple and you don't have any time problems, not even for the Neo leds. Cost price is little different and negligible compared to the entire project. Few people use FPGA because they have no experience with it. My FPGA currently uses 18% of its cells.

I have just put the first video of my "superkogelbaan" online. It mainly shows the details of the different modules used. You can see details of the control sensors. It is a first real video shooting test. I have tried as much as possible to display the overview of the modules. Towards the end there is also a short overview of the hardware controller. This is rather limited and will be shown in more detail in another video later on. The video is in full HD 1920x1080 50p.

I hope this first video will help you to understand how the "superkogelbaan" was built. At the end of the video you can see a number of drawings of the trajectories. You can select these routes with just a few buttons. I am now working on a complete book with drawings for the children. Then they only have to choose a drawing to make the right settings. A number of pre-programmed tracks are now also created in the FPGA controller. These can be selected by the children to execute. It can't be easier to use. But they can still change the routes during the implementation. They can also change this via the IR control. I have 43 keys on the IR control of which about 30 touches are already in use. When a new key is needed, the code can be read from the LCD display in real time. Position of the motors, sensors, servos, yes all of them can be read while the balls are travelling along the tracks.

The video shows the colors of the Neoleds completely wrong. In reality the colors are beautiful green and red. This is because the video sensor shows too much blue light and is therefore overexposed.

New change in the way I operate my super "Kugelbahn". I bought a Fischertechnik controller TXT. I'm going to place this controller on the top layer to control the programs. In fact, this controller doesn't have to work much. All macro functions have already been programmed in the FPGA. Positioning, counting, controlling servos, etc. are all functions for the FPGA. For example, the information of a servo is very limited, it is only on the left or on the right. A servo data info for the Fischer controller only needs to be 1 bit. This gives the TXT controller sufficient information on the state of the servo. I have a number of counters with 2 digit information. They are used to count the number of balls coming along. If I pass this value on as an 8-bit integer, the TXT controller can process this information. All this data I am going to process via the external I2C connection. To do this, I only need to include the driver in the FPGA. I have already connected the TXT controller to my FPGA console:

Meanwhile, the ROBOPRO program runs perfectly together with the PC and the USB link with the TXT controller. A small test program allows me to view the I2C communication. This way I see the levels, timing, data, protocol etc. Here is a picture of the programming environment:

Everything looks good, I can now also evaluate the load on the I2C line. My FPGA is a 3.3V type connection, I don't need a level converter. I wonder if I still have to provide both signal lines with a pullup resistor. For that I have made an adaptable setup. The pulup in the TXT controller probably turns out to be around 3K3. I have also added 3K3 myself. Then the positive edge of the signals is much better. However, if my FPGA is off, the line voltage becomes 1.75V. When connected in this way, the TXT controller no longer works because it sees the bus as occupied. This is correct. I can still see a lot of details that are important to write my own driver into the FPGA and to correctly adjust the hardware. So, a decent task for the next few days!

Tests with the Robopro software and the FPGA via I2C are running smoothly. I can read all data from the FPGA and send back commands. I am using the software in online mode. Here's a small example of how things are going:

Of course this is only a start, now I can already read out all the data that is needed. I can also send commands to the FPGA. This allows me to develop full programs on the Robopro software. This is very fast and on a full 32 inch UHD screen you have a very good overview. I am now going to draw the trajectory completely on my screen. In a very short time I have such a working system. I only use the I2C interface of the TXT controller and the Robopro software as all control functions are already provided by the FPGA.

The Robopro program is now working and the measured values of the FPGA controller will now appear on the 32 inch screen in real time. The blue lines are software LEDs that are controlled by the program. They indicate the actively selected track. The small black blocks contain counter values. The elevator is at 68m altitude, 47 bullets have been raised along the escalator, the 4way selector is on track 2, there have been 32 bullets along the ketting1 and also the wormL and wormR have been marked. The number of bullets that can be moved into the elevator can be set between 1 and 5 (at the bottom of the "verdeler") and is now set to 4.

The elevator contains 2 x 5 additional software LEDs on the screen. These indicate how far the elevator has come during the ascent and descent. The Robopro software runs quite fast. There is only 2.6ms CPU time between each data block from the FPGA. Between each I2C access there is 920 usec. Via the I2C, 7 registers of 8 bits each are read from the FPGA and 1 byte of data is written to the FPGA.

Especially the ability to interactively change the screen according to the settings times running the bullets is really super.