Gunners TekZone

I suspect LEGO TC Logo does that (and I did set it for the correct slot I am using #2), as it will control four of the ports (2, 3, 4 , 5) if I use their "opposite" numbers. Eg: #5 for port 2. Same results with BASIC. I can POKE the values 4, 8, 16, 32 to toggle port 5, 4, 3, 2 respectively.

Well, I pivoted... I (belatedly) realised that the person (David Mutimer) who had made the schematic I was referencing, had also designed a PCB... Doh... https://drive.google.com/open?id=1hLzV6ZpXksdaTLoTwjweyCBjj207bmnd A whopping $6 CAD later and I had 5 of them (in glorious red) from PCBWay. And the chips to make two... And so I did. So, I am testing with LEGO TS LOGO and oddly, they both have the same issue: Ports 0 & 1 are always ON, which is no good. And ports 2, 3, 4 ,5 work as expected, but are referenced backwards as 5, 4, 3, 2. And it seems both inputs register as TRUE, all the time, although they indicate properly on the Interface. Well mostly... there is odd interactions when using both, but only when plugged into the card. So... something is not playing nicely with something else on the cards. I am going over the data sheets of the support chips I picked up from Digikey (SN74LS245N and SN74ALS74AN) vs what the schematic shows. Or, perhaps it is the fact that I am running the older SY6522A vs the schematic indicated newer WD65C22 ??? Cheap, YES. Simply works? Not so much Joys of old parts I guess.

Nope*... Control Lab (which I believe was only part of the DACTA educational system) was out about 2-3 years before the RCX came out (for retail sale) with its own dedicated control system (RIS). * Not Natively... But almost anything is possible with 3rd party interfacing (Arduino, etc.) for simple remote control. I was able to control a 12v train from the Interface-B, via Control lab... By timed motorization of a 9v polarity reversing switch wired to the 12v system (Worked well, but things could get a little warm and melty if the train stalled or derailed just right to allow current to build up in that wee switch).

Honestly, I have no idea if the Interface-B used anything more than 5V TTL level serial??

The Interface will automatically start listening for the "###Do you byte..." transmission, and if that connection is successful it spits out the "Just a bit..." and a stream of port data. However this will stop after about two seconds if it doesn't get back a regular "keep awake" signal. Thus I used a TTL-USB and terminal program, set on repeat, to send out the "###Do you byte..." and then started probing to see if this date got to the CPU, and if it did, start probing to see how far did the response make it out. Now, if your scope can translate Serial signal to text, as some have the option to do, then you can easily see if the probed data is clear or corrupted along the way as you go. For myself, my scope doesn't support that, so I just used the same TTL-USB "receiving" line to do my probing analysis.

Sorry if getting off track... Although I do believe that using a "newer" hardware, running various software that can fully read and control the Interface-B is what I currently have going... To supply a summary of MQTT (as that is all I understand anyhow) is that it is a communications protocol that Publishes (sends) and Subscribes (receives) messages to and from multiple diverse devices. The MQTT Broker program acts as a central distribution hub for this process. In my case I have an ESP32 running Bliss's MQTT program for the Interface-B. This program Pubishes (sends) out Input port data and Subscribes (receives) values for the Output ports. I use this process via my "control flow" on Node-Red (which is independently doing other stuff as well). My MQTT Broker and Node-Red run on a Raspberry Pi... Thus I am using two different "modern" hardware devices and a few "modern" programming languages (Python and JavaScript) to orchestrate the Interface-B action. Personally, I am trying to do both... Control the Interface-B with anything other than Control lab on a full PC, and the RCX as a remotely controlled device under the same centralized oversight. Thus, while I have not yet integrated such, I would like to expand my existing process to also interact with RCX. Although I would probably prefer to use another ESP32, communicating to Node-Red via MQTT to control either a LEGO IR Tower (or just an IR transceiver) to send/receive RCX compatible codes. Thus a button press on an Interface-B can activate an action on one or more RCX bricks, and vice versa.

Same. Mine is a RPi3b+ that runs my MQTT broker and Node-Red service. I run it solely internal and "headless", as in no KB/display but still running the desktop with local VNC access. Node-Red can read and control all the inputs/outputs on the MQTT connected Interface-B, and handles the "logic" of what to do and when.

BTW, I can't recall if I did it on purpose, but I tapped the Serial GND from somewhere in the upper left corner of the board... See my picture showing that location, in a prior post. Also... It appears you still have the original serial circuit connected? I believe I cut mine out or the loop completely, to avoid and possible feedback/crosstalk/insert tecnobable here.

That would be my recommendation as well... I had noted poor signal via those wires in my tests, even though they looked fine. Even the cheap dupont wires are better than those oldy moldy ribbon cables.

You can go a step further and put in an ESP32 in lew of the TTL-USB... Now you have a standalone WiFi capable Interface-B that is controlled via MicroPython. https://www.eurobricks.com/forum/forums/topic/200778-project-programs-to-allow-interactions-between-old-lego-control-interfaces-rcx-lego-interface-b-others/ I have one of mine somewhat like that, only externally connected via it's normal (working) Serial interface. This one acts like an MQTT client to switch a household lamp. One of my many ideas is to (eventually) embed it into the Interface-B that currently has the TTL-USB. Then with a small switch wired to a GPIO and some additional coding, make it act as a switchable WiFi capable device running MicroPython code, or just as a simple USB Serial device for use with the usual Control Lab etc.

Ha, yes... that's why I tapped into the corner area. 5v should be fine, but I did switch my TTL-USB to 3.3v just in-case the CPU couldn't handle the 5v long term. I also replaced ALL the ribbon cable (the remaining wires were just power and GND) to make it even more flexible to assemble. Hot glue looks messy, but it holds and can easily be removed with some IPA if needed.

@Wapata Very nice! Another old LEGO Interface-B is resurrected. Arduinos still have purpose! OK, a Mega is a wee bit overkill, and a space hog... But still sexy in it's own way as a great diagnostic tool

Hello. Sorry about that... My posted pics tend to get purged as they are hosted from a free Dropbox plan, and space eventually gets used up then cleared. I do try to remove the dead links, but forgot about this one. I don't think there is a trace from that 3rd connection. I am not sure what that particular component is supposed to be... Perhaps a transistor being used as just a diode?? In my case I first tested the full serial functionality of the Interface-B by using a TTL-USB adapter to tap into Pins 22 (TxD) & 21(RxD) from the main IC 80C515. Once I confirmed that the Interface-B was otherwise functional. I connected the TTL-USB to convenient locations traced out from the main IC. I did find convenient side by side locations for such around the mid/upper left side of the board. And becasue of the whole ribbon cable rot, I simply cut all out the Serial stuff and placed the USB/TTL adapter in place of the DE-9 socket. I did have to move (replace) the large cap to make space. I hope this helps.

I don't do the IoT thing much. I prefer to keep my home networking, as limited as it is, entirely away from the cloud. And since I don't get out much, that works just fine for me My current experiment at least keeps my MQTT credentials entirely mine, no need to share with a web based application.

Well, I had a thought (it happens once in awhile )... How to link two different Interface-Bs that are running under completely different processes? So, it turns out that a simple 9v style cable between two interface-Bs, one on an output of the 1st and the other end on an input the 2nd just works... Even if the only other thing they share is the power grid. Which makes sense once I thought of it... One is essentially "closing the contact" of the two wires in the cable, while the other is seeing that as a simple switch. So just for giggles, I have Bliss's blocky program taking a button press from my LegoB2, processing it as an output on LegoB3 which is wired up to my 3rd Interface-B (formerly LegoB1) running independently off it's usual ESP32, and processing my Node-Red (on an Raspberry Pi) running (amongst other processes) a MQTT lamp control flow. Thus in a simple roundabout way, I can have Blocky running logic to control an entirely separate MQTT setup. This is what I call FUN in my foggy moments

Hmm, yes, I just might have the parts after all ... I got the same Serial to TTL 3 pack as you probably did, and I am sure I have an HC-05 or similar from back when I messed around with that more often. That said, I'll leave the Multi-Wireless-Serial stuff to whomever really wants it. Most of my testing setup and connections are already cramped and a nuge away from disconnecting themselves as is

Ahhh... I see how those One Shot blocks work now. Thanks! To keep with the multi-interface testing, I setup my ON switch on LegoB1, the OFF on LegoB3 and the target outputs on LegoB2. Working just fine! And that variable swap seems to work nicely as well! Perhaps (if easy) just make that variable setup a "built in" function block, so one can use it or not as they chose? I is confused ... again... So, this is running the webpage (WiFi) and controlling the Interface-B (BT) solely from a phone/tablet? Well after the whole Rube Goldberg TTL/BT/Serial setup of course. That was some nice jerry-rigging! Not sure how that would work with multiple interfaces?? Alas, I don't believe I have enough bits-n-bobs to set that up for testing. Hmm... Personally, I would just have the same physical PC/Tablet with wired USB and simply VNC to that with a phone. But even that seems unnecessary as your current application is all about the programming of, not the "control" of the program... Not unless you are planning on adding GUI based control/display options as does Control Lab?... Just with Blocks instead of LOGO.

Ah, yes... Something like that, but in the background code. But again... Please don't stress about it, I'm not I am not your ideal target base. I tend to run out of steam too soon, thus rarely get far in making my own big projects before I have to set them aside... And promptly forget much of what I learned. But I do like smaller ones, like testing for others... So this is that!

Hah... This old dog don't like new training for something he isn't likely to use outside of testing... But who knows... "I'm a man, but I can change, if I have to, I guess". As for the output labeling, again not a big concern if others don't care, but I am very use to the alphanumeric distinctions between Interface OUTPUTS and INPUTS. The logic you describe could probably accounted for in the back end, as an "A" label for an Output will always == 1, as will a 1 == "A". HEXADECIMAL does it... But then that is confusion all of its own. However, that is added complexity for the program, while us "meatbags" are somewhat more adaptable... So I will survive That said... I do not understand what these do? And your example doesn't even seem use them?? But that falls under "learning blocky" and I might forget how to feed myself if I cram too much "new" through the brainfog

But in my slapped together test, once activated the port on B3 stays ON... EDIT: Well, that was before my 2nd IF block was added... With which it will turn OFF, if I time it just right Normally I would use something like an IF/THEN/ELSE, but I don't currently understand that equivalent in Blocks. 2nd EDIT: This was just a whimsical test to see what happens to a running program if the STOP button on the device with the button was pressed, then later released.... Turns out it just keeps on keeping on, as expected

Yes, this seems to work as described. I tested by both disconnecting the Serial end (Disconnecting the Interface-B but leaving USB/Serial adapter "visible" to the O/S) and by just disconnecting the Interface-B from the serial connection. Same results... Program stops and will not run until missing device is physically connected and made active. It did retain the prior device name/number. As an aside... I suggest changing OUTPUT labeling from numerical to the A, B,C... H as indicated on the device (and referenced in Control Lab). Also... As I previously mentions, I generally don't do Block type programming, mainly as they seem to keep changing how they are interpreted, depending on the program implementing it... whereas Python teds to stay a bit more universal (within versions at least). To clarify, I am confused here... There seems to be a way to check for an ON but not an OFF on an Input port? Or am I just misunderstanding the logic flow? Highly probable as I am only on 1st coffee...

OK... That "issue" (one of my interface's Serial connection is very loose) was really the only issue I ran into with my initial and simplistic test, so good to know that it is expected behaviour. Microsoft Surface 3 Pro running Windows 10 Pro 64bit.

OK, I finally jury rigged a 3 device multi-Interface-B setup. I rarely use block type programming but it is simple enough, so I successfully toggled ports one ON and OFF, in alternating fashion, on LegoB2 & B3 with each button press on LegoB1. I have noticed that if one of the interfaces is temporarily disabled (due to loose serial connection) then everything stops. Stopping and restarting the sketch will not work. It requires disconnecting/reconnecting ALL Interfaces in order to get back to operational condition. And in the case of one of my Interface-Bs, whenever there is a device issue, even if it is a different one, it throws a BufferOverrunError: And I have to physically disconnect and reconnect it on the USB hub, else it usually connects as the next device number up (AKA LegoB4 when it is normally B3). But as that particular Interface-B is one that I surgically replaced it's internal Serial circuitry with an internal TTL/USB device... who knows... it might be a bit quirky? I'll have to swap them around and see if this issue follows the device or stays with the last one connected. Anyhow, that is all I can work on tonight. And @Bliss I will probably DM you with further troubleshooting posts for the time being, and limit my public posts re: this testing, for more relevant announcements.

Heh... So sorry... I tried, but was hampered by lack of energy/focus... And as it turned out, lack of available USB ports on my already overloaded daily driver laptop. But I am trying to maneuver some projects around to get one of my "dedicated to LEGO" Surface tablets (and appropriate USB hub) setup with my three Interface-Bs... All in my main "living/functioning" space. EDIT: Done... And I posted 1st results in the other topic you linked above.

Ya... I was silly and purchased a big batch of Mindstorms LEGO about 3-4 years ago. Parts, books, software, the RCX Bricks, a couple of blue scout bricks, some trans-blue lidded thing with a couple of built in motors, and a wider old-grey model also with a couple of built in motors. But I never really found a use for them. But getting a bunch of them to act under remote control from a Python controler sounds like fun. I did experiment a bit doing such, using my bench RCX and the code that Bliss had made about a year ago.