| steffalk |
| Spezialist |
| Stefan |
| Karlsruhe |
|
| Software, Schlagzeug spielen, fischertechnik |
| Männlich |
|
| Saturday, October 29, 2005 |
| Friday, September 10, 2010 3:01:46 PM |
1,289 [2.84% aller Beiträge / 0.72 Beiträge pro Tag] |
|
Tach auch!
Eine Erfahrung hab ich: Pass mit den Kleinteilen auf. Uns ist mal eine 60*60*30-Kassette mit lauter Kleinteilen (Riegeln u.a.) einfach verschütt gegangen. Nicht wirklich tödlich, aber doch ärgerlich.
Die Verpackung würde ich irgendwie "dicht" wählen, so dass auch bei Ruckeln keine Kleinteile herausfallen können.
Gruß, Stefan
|
Hello again,
Carel, I'm totally fine with those closed loops. What I meant is that we agree that we don't have more closed loops available than RoboPro can trigger inside of the RoboInt. Anything beyond this requires that we write software running *inside* of the RoboInt. Agree?
Regards, Stefan
|
Hello Carel,
Thank you for your explanations. Two questions remain:
1) What is this RS232 listener? A piece of Hardware sitting between the PC running RoboPro and the RoboInt? Some RS232 sniffing software? Or is the RoboInt connected via USB, and you connect some device to the V24 port on RoboInt, "at the other side" of the RoboInt?
2) We agree that we must send higher-level functions (as the example with the motor counter suggests). But if we use RoboPro, we only may use the functions RoboPro offers, right? Or do you have some means to overcome this limitation and still rely on RoboPro?
The rest, that is, the communication between the two endpoints using IP, SOAP, WCF, whatever, is clear. Thats the easy part (besides securing it, to be precise).
Regards again, Stefan
|
Hello,
@Carel: Sounds interesting. You mean, the client runs RoboPro (told it to use V24), sniff the V24 traffic, send it over the internet to some software talking to its local V24 and thus speeking to the RoboInt? If catching the V24 traffic succeeds, the rest is easily done (not said easily secured).
Although, again, for what scenario would such a setup make sense? Taking the unpredictable timing into account, turning a motor until som condition at the model is met is a bit risky imho.
Best Regards, Stefan
|
Tach auch!
Und gleich kam eine Mail von jemandem, der heute früh noch .CSV von der 1.0 geladen hatte und diese Funktionalität in der 2.0 vermisste. Dem Manne konnte aber trotzdem vorab schnell geholfen werden: Siehe http://www.ftcommunity.de/downloads.php?kategorie=Einzelteil-+und+Preislisten. Da gibts ganz unten (http://www.ftcommunity.de/data/downloads/dokumente/einzelteilundpreislisten/fischertechnikdatenbank2.0auszugstand20100828.zip) eine Microsoft Excel 97 - 2003 Datei mit folgenden Auszügen aus der ftdb 2.0:
- Artikelnummern (auch bei mehreren Nummern für denselben Artikel),
- Stücklisten, und
- Informationen über Bilder einschließlich Link direkt zum Bild auf[url]http://www.ft-datenbank.de[/url]
Vielleicht ist das ja für noch jemand anderes auch nützlich.
.CSV-Download wird natürlich wieder reinkommen (ohne dass wir einen konkreten Termin nennen).
Gruß, Stefan
|
Hello Tovenaar,
just pass me your e-mail address and I'll send you the project. You can then alter and compile it on yourselves as you like.
In total, you should install:
* .net 4.0 (client profile is sufficient) on machines on which you will run the server or client application.
* VB 2010 (Express should be sufficient) on your development machine.
* Either UMueller's umFish (see http://www.ftcomputing.de on the development and target machines, or I'll send the one needed umFish40.dll along with the project.
You will have to agree with yourself about a TCP communication port (default is 12345), get to know the two external (internet-side) IP addresses and the IP address of the "server" computer's NIC, and enter this in two .config files (server/client), as well as let your internet firewall pass traffic for the server computer to that computer. We can clarify the details later, of course.
I still clearly declare that I do not find that little demonstration software ready for any useful production scenario. Hopefully, I didn't make too stupid security errors (both Frederic and Frederik are still alive, and didn't report their PCs were blowing up), but as a matter of fact there remains work to do in order to get this to some acceptable quality level. The code has been just written down quickly yesterday night, and there was nearly no serious security analysis and testing. See the embedded comments for suggestions and examples. Use this code on your own risk.
If you want, you may very well test the software just using two computers in a LAN, so you are less likely to be attacked via internet.
Best Regards, Stefan
|
Hello again,
Thanks to Frederic and Frederik, who served as (very) patient testers (note: Sven offered to test also, but was in bed already), and thanks to Ulrich Müller, whose FishFace .NET wrapper is used here, there is now an absolutely minimalistic server (controlling a motor and listening on a TCP port) and client (listening to a fischertechnik switch and sending ON/OFF to that server via TCP and Internet).
To keep you from going this way here is the source code (without the configuration files where you can configure the IP addresses, ports, and so on). The code ist Visual Basic 2010 for .NET 4.0 (client profile is sufficient).
Server:
Code:Imports System.Net Imports System.Net.Sockets
''' <summary> ''' Demo of a TCP server, listening on a configurable IPv4 port and address for remote ''' connections from an allowed remote IP address, and controlling a fischertechnik ''' motor using a Robo Interface. ''' </summary> ''' <remarks>WARNING: This is by no means production-ready code but just intended to ''' demonstrate one principal possibility to tackle the problem. Use this code at your ''' own risk.</remarks> Public Module Main
Public Sub Main()
Const Motor = FishFace40.Out.M1
Console.WriteLine("Opening Robo Interface with serial number {0}", My.Settings.RoboInterfaceSerialNumber)
Dim roboInterface As New FishFace40.FishFace
roboInterface.OpenInterface(My.Settings.RoboInterfaceSerialNumber) Try
Dim allowedRemoteIP = IPAddress.Parse(My.Settings.AllowedRemoteIP)
Dim listener As New TcpListener(IPAddress.Parse(My.Settings.ListenerAddress), My.Settings.ListenerPort)
listener.Start() Try Do Console.WriteLine("Waiting for connection (blocking)") ' TODO: Use non-blocking calls. Using client = listener.AcceptTcpClient
Dim remoteAddress = DirectCast(client.Client.RemoteEndPoint, IPEndPoint).Address
Console.WriteLine("Connection attempt from remote address {0}", remoteAddress)
If remoteAddress.Equals(allowedRemoteIP) Then Console.WriteLine("Remote address is valid, waiting for commands") ' TODO: Ensure that the remote client is trusted. ' TODO: Use encrypted and possibly digitally signed traffic. ' TODO: Authentificate the client using some credentials. Using stream = client.GetStream Using reader As New IO.StreamReader(stream) Do Select Case reader.ReadLine.ToUpperInvariant Case "ON" roboInterface.SetMotor(Motor, FishFace40.Dir.Rechts) Case "OFF" roboInterface.SetMotor(Motor, FishFace40.Dir.Off) Case Else Console.WriteLine("Unknown command; terminating connection.") Exit Do End Select Loop End Using End Using Else Console.WriteLine("This remote address is not allowed.") End If End Using Loop Finally listener.Stop() End Try Finally Console.WriteLine("Closing Robo Interface") roboInterface.CloseInterface() End Try End Sub
End Module
Client:
Code:Imports System.Net Imports System.Net.Sockets
''' <summary> ''' Demo of a TCP client, listening to a fischertechnik switch on a Robo Interface and ''' sending the state changes as commands to a remote server. ''' </summary> ''' <remarks>WARNING: This is by no means production-ready code but just intended to ''' demonstrate one principal possibility to tackle the problem. Use this code at your ''' own risk.</remarks> Public Module Main
Public Sub Main()
Const Switch = FishFace40.Inp.I1
Console.WriteLine("Opening Robo Interface with serial number {0}", My.Settings.RoboInterfaceSerialNumber)
Dim roboInterface As New FishFace40.FishFace
' Using Robo Interface on COM1: roboInterface.OpenInterface(FishFace40.IFTypen.ftROBO_IF_COM, FishFace40.Port.COM1, 100) ' Using Robo Interface on USB: 'roboInterface.OpenInterface(My.Settings.RoboInterfaceSerialNumber) Try Dim remoteIPAddress = IPAddress.Parse(My.Settings.RemoteIPAddress)
Console.WriteLine("Connecting to remote server at IP address {0} on port {1}", remoteIPAddress, My.Settings.RemotePort)
Using client = New TcpClient ' TODO: Ensure that the remote server is trusted. client.Connect(remoteIPAddress, My.Settings.RemotePort) Using writer As New IO.StreamWriter(client.GetStream) ' TODO: Use encrypted and possibly digitally signed traffic. ' TODO: Authenticate with the server. Console.WriteLine("Observing switch, press any key to stop.") Do Until Console.KeyAvailable roboInterface.WaitForChange(Switch, 1) If roboInterface.GetInput(Switch) Then Console.WriteLine("Sending ON") writer.WriteLine("ON") Else Console.WriteLine("Sending OFF") writer.WriteLine("OFF") End If writer.Flush() Loop Console.WriteLine() Console.WriteLine("Disconnecting") writer.WriteLine("QUIT") ' Invalid command for the server, causing it to terminate. End Using End Using Finally Console.WriteLine("Closing Robo Interface") roboInterface.CloseInterface() End Try
End Sub
End Module
Anyone interested may have the complete Visual Studio 2010 project, of course. Just drop me a note. And: This code is really primitive. No clean shutdown, no background processing, no <insert any useful feature here>. Please feel free to ask any questions.
Best Regards, Stefan
|
Hello again,
I will try to set up a program as minimalistic as ever possible to turn a remote motor on or off if a local switch is on or off. Just so you see what amount of code is necessary (not much, really, but still more than you might expect).
On the long run, I see that approach of just remoting the RoboInt as too limited to be useful. Suppose that a motor must run until an end switch is pressed. The - unpredictable - delay over the internet might be so long that the motor may well run over the limits of the model, possibly causing damage. Also, I just don't see any value in this scenario.
If we want to get any value, we must exchange *higher level* commands, such as "move that motor until that switch is pressed". An that brings me back to my framework for having realtime applications controlled in .net running on the PC. The key to realtime is to move operations needing guaranteed timing off the PC into a local device such as the RoboInt. And if we can do this going over USB, we can as well do the very same going through the internet (even via e-mail, if you want ). My framework (which is work in progress, but already functional and very promising) isn't interested about what kind of interface (RoboInt, IntInt, Lego, whatever) is attached how (USB, V24, Internet, whatever). Perhaps, when my current Printer project (which uses this framework) is finished, I drop in a few classes remoting whatever command you want over the internet.
Regards, Stefan
|
Hello again,
OK so far. So a ft switch connected to my interface will control if a motor on your interface is on or off. This alone is pretty easy to implement.
Question: Do you want a working application for both PCs that can do that (with source code, of course)? Shall we program that for you, as simple as possible, just to see the principles?
Or are you interested in a general framework or application for such a purpose, that can be configured to some extend without coding? This might take a bit longer.
Regards, Stefan
|
Hello again,
(staying with English so all readers of this thread can follow)
@Tovenaar: I understand that You (at your home) want to connect the outputs of your Robo Interface to the inputs of mine (at my home) via internet? Kind of "Proxy" between them? Not that you run some software on your PC and thereby control my Robo Interface?
Regards, Stefan
|
|