RoboPro 3.1.3 with I2C!

[thkais]

Hallo,

@qincym: Eine Relais-Steuerung ließe sich mit einem I²C-Urgestein, dem PCF8574 aufbauen. Dies ist ein Port-Expander (ein Beispiel für diesen Chip gibt es in RoboPro). Ein Transistor und ein Relais - fertig ist die Laube.

[qincym]

@thkais,

danke für den Hinweis! Den Baustein I2C-Porterweiterung (Conrad # 198848) wollte ich sowieso für die Abfrage der beiden End-Taster benutzen. Jetzt werde ich ihn auch für die Steuerung des Stiftes verwenden.

Viele Grüße
Volker-James

[vleeuwen]

The AMIS30624 (TMC222) suistable stepper controller is a nice device for positioning but is it also a good device for 2D plotting?

For 2D plotting there also needs to be a relation between the speed of the X and Y stepper and this need to be in synchronisation.
With the AMIS306-- serie (30624) this synchronization is rather difficult to obtain.

See also the commandset of this stepper controller
(for example
the Allegro A3984 http://www.onsemi.com/pub_link/Collateral/AND8404-D.PDF
or
the L9942 Stepper Motor Driver for Bipolar Motors with microstepping & programmable current profile http://www.st.com/internet/automotive/p ... 116437.jsp).

More suitable to to take a Microcontroller with 2 sets of stepper outputs devices and implement/program your or own 2D I2C commend set.
See also: http://web.inter.nl.net/users/Ussel-Int ... ppers.html

[vleeuwen]

Maybe this can be helpful for motion control?

http://www.trinamic.com/index.php?optio ... Itemid=287

[Ad2]

In my plotter (mechanically identical to the original), I used the AMIS controllers (almost equivalent to the Conrad TMC222 controllers). They have an input for an end-switch, so you don't need a port expander for that. I also see no advantage in using a relay to drive the solenoid, just control it directly from the TX. The point Carel mentions is a valid one. The advanced features of the TMC222 are hardly benificial for plotting because of the tight synchronisation of the motors. The TMC222 commands are geared to make movements (i.e. goto a specific position) rather than individual steps. The Bresenham algorithm is however based on steps, the only possible optimisation here is to gather steps in the same direction into a single move (run slice algorithms). Bresenham takes n steps in the major direction and then a diagonal step, so in the major direction the motor will make n, 1, n, 1, n etc. steps and in the other direction a single step when the major motor makes a single step. I tried to optimise this further with 45 degrees lines but this failed. Even with identical settings for speed and acceleration the lines weren't straight but had curls at the ends. This is probably due to the difference in inertia of the two motors but still strange because the motors were programmed for the same acceleration and did not lose any steps. Note that when the pen is up you can benefit from the direct positioning of the motors because the exact path does not matter. The run slice algorithms you can find on the net are for 2D plotters. Bresenham also exists for 3D and 4D (and probably higher), which could be useful for the 3D printer. In this case the optimisation is easier done with an 'afterburner' algorithm that keeps gathering steps in the same direction and once there is a change of direction, issue the command for the saved steps as a single move.
Note that when I built the plotter, I2C was not available yet on the TX and I used my own RS485 to I2C bridge. The Bresenham algorithm was acually running on that bridge and for RoboPro this just looked as normal encoder motors with advanced motor control. In this case however 'synchronisation' would not mean the motors would run at the same speed but meant that the motors would reach their destination at the same time.

[vleeuwen]

Thanks ad.

The TMC222 is also a device from Trinamic not from Conrad:

Product info
http://www.trinamic.com/index.php?optio ... Itemid=311

Overview
http://www.trinamic.com/index.php?optio ... Itemid=288

http://www.trinamic.com/index.php?optio ... s&Itemid=1

[qincym]

@All

Thanks! Your hints and advices will all be considered.

Best regards
Volker-James

[vleeuwen]

Hi Ford,
I am curious about the time that a refresh of the display will cost in practice.

640*480 =307200 pixels.
for b/w 1 bit/pixel =>38400 bytes,
( for gray scale orcolor 4 to 8 bits/pixels)

In theory
In the online mode TA refresh rate is 10 msec at least.
I2C => max 4 bytes/TA cycle.
38400 bytes will need 9600 TA refresh cycles. => 9.6 sec for B/W full refreshment of the display.
I hope that I did not made a mistake?

[vleeuwen]

Hi Ford,

The same for your actuators and sensors.

However my suggertion is to use a microcontroller board, for example a PIC32 (a version with support for 2 or more I2C busses) developments board (See microchip), as preprocessor.
One I2C connection is in use as slave and connected with the TX-C and the second I2C connection is serving as master for the sensors and actuators.

The preprocessor:
1) takes care of processing the raw data from the sensors and for the actuators.
2) it communicates with the TX-C with only the high level data.
Most of the time the amount of high level data is not so big.

With this construction your are able to create very smart sensor/actuator systems.

This solution extends also the TX-C with very fast local closed control loops. because the internal algoritme does not depends of the 10 ms TA refresh rate.

In fact a simular solution as LEGO but now you are free to choose you own preprocessor board and development system.
In your case maybe a nice graphic oriented or DSP one.

[vleeuwen]

@Ford,
I don't no.
Speed is a relative notion. The performance has also something to do with the objective of the aplication.

I only mention the PIC32 and as example only because I am happy with the development system and the support from Microchip. It is not limitative. There exist a lot more good microcontrollers and development systems.

[thkais]

Moin,
10-20kbps sind wirklich etwas dünn - der ATMega könnte mehr. Alles eine Frage der Software.
Aber schiere Geschwindigkeit ist nicht alles - man handelt sich mit hohen Bitraten ganz andere Probleme ein. Je höher die Bitrate, desto höher Störausstrahlung und Störanfälligkeit. Im Umkehrschluss muss man dann bei den Kabellängen kürzer bleiben oder geschirmte Kabel verwenden. Unter diesem Aspekt könnte es sogar Absicht sein, dass der Bus so langsam läuft.
Schlussendlich bleibt die Frage, wie oft das OS eine Übertragung initiieren kann - denn hohe Bitrate ist nicht alles, die Daten müssen auch zeitnah verarbeitet werden. Hierzu stehen noch Messungen aus. Aber hier stellt sich wieder die Frage: Erwartet man ein Interface, das "Spielzeug" steuern kann, oder eine industrielle Steuerung?
Schlussendlich muss aber sowieso ein intelligentes Management der Sensoren programmiert werden. Bei Temperatursensoren macht eine hohe Abfragerate (hier ist nicht die Bitrate gemeint, sondern die Abfragefrequenz der Sensoren) kaum Sinn, während Beschleunigungssensoren u.U. sehr oft abgefragt werden müssen. Man kann den Bus mit unnötigen Abfragen verstopfen oder einen langsamen Bus optimal nutzen.
Bei der Anzahl der Sensoren wäre ich auch etwas zurückhaltender. Jedes Device benötigt Strom und belastet die Datenleitungen. Realistisch könnten 10-30 Devices sein (ist abhängig von der Beschaltung der I²C-Schnittstelle und der Auslegung der Serienwiderstände), aber bei einer Anzahl von 120 wage ich mal vorsichtig zu behaupten, dass das ohne weiteres nicht möglich sein wird. Hierfür gibt es aber Repeater, die das Signal verstärken und dadurch die Anzahl der Devices erhöhen können.
Der I²C Bus wurde ursprünglich entwickelt, um Datenübertragungen innerhalb einer Platine / eines Geräts abzuwickeln, z.B. bei Videorekordern die Tasten und das Display (7-Segment). Also eigentlich keine großen Datenmengen und nichts zeitkritisches. Zwar wurde der Bus in den letzten Jahrzehnten immer wieder mal erweitert (400kbps sind nicht das Limit), aber das Grundprinzip bleibt. Schnelle Datenübertragungen über weite Strecken (als "weite Strecke" würde ich hier alles über 20-30cm sehen) sind nicht die Stärke des I²C, dafür gibt es bessere Schnittstellen. Eine dieser Schnittstellen, die sogar in abgewandelter Form in Autos und in der Industrie verwendet werden, besitzt der TX bereits: Die RS-485 Schnittstelle des Extension-Bus ist ein Vorläufer von CAN und auch für größere Strecken geeignet.

[vleeuwen]

Hi Thomas,
See: http://web.inter.nl.net/users/Ussel-Int ... c_i2C.html
and the most recent I2C bus specification (feb 2012): http://www.nxp.com/documents/user_manual/UM10204.pdf

Abstract Philips Semiconductors (now NXP Semiconductors) developed a simple
bidirectional 2-wire bus for efficient inter-IC control. This bus is called the
Inter-IC or I2C-bus. Only two bus lines are required: a serial data line
(SDA) and a serial clock line (SCL). Serial, 8-bit oriented, bidirectional
data transfers can be made at up to 100 kbit/s in the Standard-mode, up to
400 kbit/s in the Fast-mode, up to 1 Mbit/s in the Fast-mode Plus (Fm+), or
up to 3.4 Mbit/s in the High-speed mode. The Ultra Fast-mode is a
uni-directional mode with data transfers of up to 5 Mbit/s.

It is a typical streaming and asynchronous protocol, not realy design for (semi) realtime use.
The RoboPro I2C implementation shows what this mean.
The data transfer speed of the low level I2C bus does not has a real meaning at the high RoboPro end level.
I notice that users make this mistake often.

[thkais]

@vleeuwen:
I know the I²C specification (and the strengths and weaknesses of I²C) very well, I am using I²C for more than 20 years...
Recently, I am using more and more other bus-concepts because I²C simply doesn't fit.

edit:
I²C could be closer to "real time" using intelligent devices and Multi-Master mode. But this is not implemented and a real challenge because of all the collision checking stuff...

[Peterholland]

Beim Interface-test mit dem TX-Controller nach dem RoboPro 3.1.3 download, hat die TX-Controller die Firmware 1.30.00.

gemeldet wird aber:
"Der RoboPro-Blibliothek-version ist 1.30.01
Immer wieder wird gefragt "die Firmware zu aktualisieren" (in einer Schleife / loop)......irend etwas ist nicht Stabil ?.......
------------------------------------------------------------------------------------------------------
Ich habe mit das Robo-pro-programma "LED SAA1064" aus der I2C-bibliotheek het -Conrad-LED-diplay nur einmal erfolgreich getestet.
------------------------------------------------------------------------------------------------------

Beim wieder erneut anschiessen gibt est immer wieder communication-Problemen beim Interface-test mit immer wieder:

"Der RoboPro-Blibliothek-version ist 1.30.01
Immer wieder wird gefragt "die Firmware zu aktualisieren"

Grüss,

Peter
Poederoyen NL

[Peterholland]

Das Problem hat sich erlöscht.

Der X (=pin4) Anschluss der Neuhold 3-Achsen Beschleunigungs-Senor-Module (=300mV/g) an der I1-Eingang der TX-Controller war der Ursache.

Wie beim "Windmill-accelerometer-experiment-Modell" von Rei Vilo gab es beim einschalten der TX immer ein Strichcode im (kleine) TX-Display. Nach drucken der rechter schalter verschwindet dieser Strichcode.
Dieser Phänomen war im alten Forum beschrieben (gibt es leider nicht mehr).

Wenn es keine X (=pin4) Anschluss der 3-Achsen Beschleunigungs-Senor-Module an der I1-Eingang der TX-Controller mehr gibt, gibt es keine Problemen mehr und funktionieren: die Thermometer-Modul DS1631, das LCD-Display PCF8574 und das LED-DisplaySAA1064.

- Der grund dieser Phänomen verstehe ich gar nicht ?.......Kann Jemand eine Erklärung geben ?

- Verwendung der LED-DisplaySAA1064 in das RoboPro-Flipper-Programm ist das nächste Problem.
Wie integriert man dieser im RoboPro-Flipper-Programm ?


Grüss,

Peter
Poederoyen NL

[Ad2]

I tried I2C with the AMIS30624 and the TMC222 subroutines in RoboPro and it works both in online and download mode. In online mode it is relatively slow (1 byte per 10ms). It seems there is no support (yet) in the C libraries.

[vleeuwen]

Hi Ad,

What you mean by one byte/10ms?
In case the application is using the 4 bytes I2C write, there arrives only one byte every 10 ms (TA cycle)on the I2C bus?
And in the online mode?

[Ad2]

Yes, my example was the GetFullStatus1 command which reads 7 bytes or so. In online mode, one byte is transfered over the I2C bus every 10ms. I will redo the measurements and provide you with traces from the logic-analyser in both online and download mode. Download mode is much faster.

[Ad2]

Ok I did the measurements again, first online mode:
0ms: address+W 0xC0
2ms: command 0x81 (GetFullStatus1)
10ms: address+R 0xC1 followed by address reply 0xE0
20ms: data1
30ms: data2
40ms: data3
50ms: data4
60ms: data5
70ms: address+W
72ms: command 0x89 (SetMotorParam)
80ms: data1
90ms: data2
etc.
So apart from the address cycles the transfer rate is 1 byte per 10ms

Now download mode:
0-230us: address+W, command, address+R, address reply , data1
246ms - 246.24ms: data2 - data5
246.38 - 246.47ms: address+W, command
246.95 - 247.21ms: data1 - data7
Notice the huge gap of 250ms between the two bursts! It seems we had reached the end of a time slice.
So apart from the huge gap, the rate is around 1 byte per 100us but there are irregular gaps so this figure is just an approximation
Within each byte the clock rate is approx. 328kHz. and the time from byte to byte approx. 35.5us.
I will see if I can post some screen shots

[Ad2]

I did some more measurements, the 250ms gap is still unexplained but when you do continuous reads of for example GetFullStatus2, the time slicing is clearly visible. The transfers occur in bursts of 500us and then quiet for 500us. In each burst are normally 10 byte transfers so on average approx. 100us per byte.