Lok24

Hi Vincent, I'll have a look today, stay tuned! Perhaps I'll will finish programming and can post a short video of my "test"-layout

I'm on 0.6. and just testing, but with my C# knowledge it is really hard.... But, yes , with 0.6 both Boost Color and WeD0 2.0 Dist work as expected.

Sounds very intreresting. If there are first results please report in a seperate thread (to bookmark) to discuss all the possibilities. I'm interested in that, too. Is there a chance to meet you and your hardeware in St.Augustin this year?

Nice. I'll try this! Thank you for your patience and the helpful answers. To Voltage: perhaps both? .BattLevelV .BattLevelP

Hum, I have two SBrick, same firmware-version, same hardware-version. One reports the batterys-level in volt, the other doesn't (always 0). Spooky. Is there a resaon why you give it % instead of real value? 100% of 9V (battery) is different from 100% of 7.2V (accu) whereas the min voltage for the processor is always the same. By the way, how is the syntax to access Hub[0].Stop("A") or ther methods of hub in the "Global code" I changed already public void MyGlobalFunction() into static void MyGlobalFunction() Or is this a pretty silly question for an C# - expert, which I'm definitely not?

Hi, for my project red keep (game of thrones) I used 4 EV3 and 16 Motors. The Red Keep was moved in a certain programmed circle. Shutting down of one EV3 in the middle of a circle would have crashed everything. So within the main programm every cirle always started with vmin = 6.3; for each EV3 in EV3list if EV3.Batterylevel < vmin then call emergencyStop Next "emergencyStop" was then used to stop all communication servers and clients on all slaves and master With your project you run into the same scenario, I fear: if a Hub with sensors fails....

Hi, sorry, please don't missunderstand, my posting was in no way a "ToDo" list but some things I noticed when testing your project. for example: I run a motor with a speed of 70, but distance covered depends on batterylevel. So you could add same factor to correct this, same is for the starting value for the ramp command. I did that on my layout driven by a RaspPi and some SBrick last year shown on different conventions. Of course it takes some testing with the factor

Hi, There are some small issues I found when testing: WeDo Tilt sensor is recognized but doesn't do anything (show log) Trigger on other colors (already mentioned) Get properties of Hub like . MAC-Address . Battery (in Volt) . type . FW-version Is there a chance to reset all Variables? Normally this is done at program start, but there is no real "program start" Background: to prevent from retriggering I set Hub[x].State[y] to specific values, but of course they all should be reseted to have a defined state when starting trains Get properties of the port, like . color . IsRunning . IsStopped . device connected .RampExecuting and so on Select specific MAC–Addresses only Select a specific path to get the program saved and load (now it's always the application path) or at least remember the last Clicking EDIT always opens a new window, even if already opened The Code windows have no names to distinguish Is there a chance to display the line number in case of error?

Yes, that helps a lot. Thank you fo this good explanantion. I now checked my two Powered Up Hubs and found out the following: The one which allows 2 sensors or 1 sensor and one 1 boost-motor attached has version 01 10 The one which allows only one sensor has version 03 10 I did it with my RasberryPi!

There are two in a swiss BL Store......but yes, could be more than 38 worldwide But the parts had been listed at LEGO S@H for a short time, part# is 88007, so perhaps.....

Yes, sure PoweredUp Hubs, HUB No 4

No, it doesn't trigger at all, but it's different FW from the one than works, perhaps newer than all your Hubs? And of course, there's only one sensor attached for testing. I'm just gong to find out the versions..... With the tilt: this is in no way important.

Hi, Ok, that doesn't work at all As alredy mentioned I have two poweredup Hubs. One accepts two sensors or a sensor and a boost motor. This one doesn't trigger on WeDo Distance Sensor(and this one has been Updated, if I remember corretly) The other accepts only one sensor (WeDo) , this one triggers the event The reason is obviously a different FW in the Hubs, and not your program So I've got to find out what FW-Versions I got installed by the automated process. WeDo Tilt: got no application yet, but as you asked for the Tilt WeDo 1 thought I feed some Info.....

Hello, new parts arrived, testing continues.... LEDs : work brillant and as expected WEDO Distance: connected, shows values in log, but cannot be triggered by prog (i.e. "Distance is below 3")? Waht do the values mean? WEDO Tilt: detected, but not shown in log, cannot be triggered "Port Connected: A of type WEDO2_TILT"

@Bartosz Hi, unfortunatelly I' cant edit the post nor delete it after insterting the user-tag? Strange. So, here is the only picture I've got:

The connctions are cut very quick (1-2 sec) after closing your software, immediately reconnect via handheld is no problem.

Hi, no, klicking there doesn't do anything. but I can find the MAC of course in the details of the device, but only with "weitere bluetooth optionen", so no probs with that.

Yes, much better, thanks a lot. But anti collision is still loaded at startup (but can't work, due to lack of sensors) and my "own" project is always shown as "Program #1" in the register (what is just a cosmetic issue )

Hi V0.5 doent work as expected.... 1.) Prog anti-collision-example.ltp is loaded at startup 2.) my prog shuttle-train cannot be loaded

.... no? Shows only Name....

Sounds good, but at conventions often meet many people to build a huge layout, with many different trains. And what if someone wants to test my shuttle-project with his own loco? Sure this is not the "normal" user and needs no prority , but for advaced users it's no problem to enter a list of adresses, we do that with the python/raspberry/SBrick-environment usually.

You are completely right, as it works now it is very user-friedley, but might lead to problems during conventions. Perhaps reserve a global variable in the global code, i.e. DEVICELIST="" And in your program : if (DEVICELIST == "") -> behavior like now If user fills DEVICELIST = (adr1;adr2;adr3....) then filter only these Therefore it would be useful to display the adress of a connected device somewhere. Like a "properties" popUp for each device, showing connection, adress, type, firmware, battery-level (in Volt!), connected ports and so on Just a suggestion. Going to try your your new version soon. Thanks for your work!

Yes, it is the same using your software or the handheld. And Mr Hobbles confirmed the behaviour.

Nice topic! the program gathers all LEGO(?)-BT-devices. What if the neighbour starts his LEGO-boost? What when used at an exhibition with a dozen of devices around? Idea: implementing a list of "allowed" adresses As your program doesn't use any .ini-files for the user you could set up such a list in any form in the "global" routine?

Hi all, strange! Got now a second PoweredUp Hub. And: Boost sensor + Boost motor work together! the difference: the one not working I had already connected to the App and it made a FW upgrade the one working is "out of the Box". Is there a way to read the FW-version without updating?