Trinamic Discussion Groups

[Flecko]

Hallo,
ich möchte einen Trinamic PanDrive 110 per ASCII-mode über Labview steuern, leider funktioniert das nicht. Ich habe schon Posts zu dem Thema gelesen aber die haben mir auch nicht weiter helfen können. Der Motor läßt sich problemlos über TMCL ansprechen, über diese ich den Motor auch in den ASCII-Modus schalte. Anschließend sende ich per Standartfunktion VISA write einen ASCII Befehl (A MVP ABS, 0, 50000 <CR>) an den com1-Port, aber es tut sich nichts. Ich habe es auch schon mal über MAX versucht, aber dort funktioniert es auch nicht. Der com1 Port fuktioniert aber laut MAX einwandfrei.
Der gleiche Befehl, mit Ausnahme des Prefix A und dem Suffix <CR>, funktioniert auch in TMCL.

Soweit ich mich nicht irre, habe ich habe ich die Adresse des Moduls und des Motors richtig gewählt (Es funktioniert ja auch in TMCL mit den gleichen Einstellungen).

Das kommt am com1-Port ankommt:

Port opened by process "LabVIEW.exe" (PID: 1064)

41 20 53 41 50 20 34 2C 20 30 2C 20 31 30 30 20 A SAP 4, 0, 100
3C 43 52 3E 0A 41 20 4D 56 50 20 41 42 53 2C 20 <CR>.A MVP ABS,
30 2C 20 35 30 30 30 30 20 3C 43 52 3E 0, 50000 <CR>


1. Kann mir jemand sagen wo der Fehler liegen könnte oder was ich noch probieren kann?

[Andrew]

Sorry, I do not understand German. I just vaguely guessed what you are writing

Have you checked the global parameter #65 RS232 baud rate?
You need to set the baud rate not only in the module, but also in your software. Otherwise commands would be written to port silently, no error reported, but the module would receive nothing.

I suggest you use TMCL-IDE to set any baud rate in the TMC module permanently. Then you use the facility provided in your software to set the baud of the computer to the same rate. If rates do not match, all data will be ignored by both parties.

Perhaps you should start with the software (LabView in your case). Learn how it can set bauds, and what bauds can be set.
I do have a LabView, but do not yet have time to check this. Maybe later.
If LabView can't change the baud of the computer, then you still might change the default baud of the operating system for that port. In Windows see the control panel. Change the default baud. And it should work afterwards.

Speed of communication is discussed here:
http://www.trinamic.com/ttdg/viewtopic.php?t=53

[Flecko]

I have set the baud rate on my pc to 9600 baud wich is the default setting for the PD110. All values I set in Labview match the values I have set as default values in my hardware manager. The Values are:
COM1:
baud=9600
data bits=8
parity=none
stop bits=1.0
flow control=none

Are any of those parameter to be set on the PD110 too except for the baud rate?

Is my command line correct(A MVP ABS, 0, 50000 <CR>)?

Thanks and greetings
Adrian

[Flecko]

Hi,
it works! I set global parameter 67 to 10000 and it worked. // Absolutely strange when I think about it now...
Thanks and greetings
Adrian

[Andrew]

Try also and switch to faster bauds.

Amazing how simple some answers might be sometimes! You have managed to read everything about the parameter #67 ASCII mode, but forgot to turn this mode on.

Perhaps previously you were trying to turn ASCII on from LabView in text mode.
You had to do it in binary mode. Only then switch to text.

It would be interesting to know if you could now operate RS232 in binary mode from LabView. Can you? I suppose you should be able to.
Binary mode is more time efficient.

At least working with terminal software I have noticed that ASCII mode is not very stable. Communication stops on many obscure errors. By the way, it accepts only capital letters.

I presume you meant 10000 binary, rather than decimal. It would be 16 in decimal notation.

Beware that you have turned off the bit at index 0.
With this setting ASCII will remain on only till module is shut down.
... Assuming that previously you switched ASCII on with SGP 67,0,1.
When you restart the module, 10000 binary would set it into binary mode. So next time you have no connection again.

For ASCII to work permanently you need to set all bits at once, rather than separately.
E.g.: 10001 binary or 17 decimal, instead of 10000 binary.

Though, I would suggest you use 100001 binary or 33 decimal, so that only reply is echoed, instead of the whole command.

Note also that there's an undocumented global parameter #255 Suppress reply. I have not tested if it it works in ASCII. It could save you some time in communication, by eliminating replies completely.

To switch to ASCII mode on-the-fly, temporarily, without storing anything in EEPROM, you might use a command #139 "enter ASCII mode". It is described in chapter 3.34 TMCL Control Functions of TMCL reference.

In fact it is strange that ASCII mode did switch on at all in your case.
If previously, in order to turn ASCII on, you used 1 binary, then bits 4 and 5 =0, which instructs to send at least some echo anyway. The fact that you received no echo, means that TMCM was still in binary mode. 10000 binary does not turn ASCII mode on. It sets only echo, which is meaningless without ASCII on.
The fact that 10000 binary worked, while 1 binary didn't, is strange. Maybe LabView is simply not able to accept single sharacters as echo (bits 4 an 5 =0). Maybe it accepts only complete lines (in prameter #67 bits 4 and 5 = 01 binary).

Remember that global parameters from #64 to 128 are stored in EEPROM only. So, commands SGP and STGP are equivalent on these parameters.
EEPROM usually has a life time of about 100000 writes. Do not use it often.

Your setting for the port seem to be OK.

Your MVP command is good. TMCM interprets the "ABS", "REL", and "COORD" strings correctly. You may replace them with respective numbers: "0", "1", "2".

[Flecko]

Hi Andrew,
thanks for your answer. After it worked I didn't view this site again, until now when I reseted the modul to test something in directmode. As I wanted to set my standart settings for Labview I become crazy because it didn't worked as I made it before. The strange thing is that I stored the file wich configured my EEPROM and it didn't worked like I did it the last time....??? Now I read your answer and after some tries I got it running with:

SAP 4,0,10 //maximum positioningspeed 0...2047
SAP 140,0,0 //microstep resolution 0=Fullstep
SAP 211,0,1 //Fullstep Threshold 0...2047
SGP 67,0,10001 //ASCII mode

STAP 4,0 //maximum positioningspeed 0...2047
STAP 140,0 //microstep resolution 0=Fullstep
STAP 211,0 //Fullstep Threshold 0...2047

As you said it worked with 10001. Don't know what I did...

Greatings Adrian

[Andrew]

The strange success in operation prior to reset might come from some bit staying dirty. For example a FirmWare sets one bit of some parameters, and leaves other bits dirty.
Also some parameters in TMCL FirmWare are related to others. You may discover, that you set one, and this causes to reset another. That's perhaps because they share the same bit space in TMCL memory.
One example is #136 "acceleration threshold".
http://www.trinamic.com/ttdg/viewtopic.php?t=263#787
(See pojnt 6. there.)
http://www.trinamic.com/ttdg/viewtopic.php?t=263&start=15#854
(See pojnt 7. there.)

Maybe you made an update to a newer FirmWare, which corrected some bug.

Another possibility is a mismatch between binary, hex, and decimal notation.
You quote 10000 and 10001 in binary. But you might send it as decimal, which would result in a completely another binary number.

Always remember that I discuss binary notation for simplicity. So that you easily see which bits are on.

In order to send 10001 in binary, you need to actually send 17 decimal, or 11 hex.
This would Echo back complete command, and turn ASCII permanently on.

To echo only replies, and turn ASCII permanently on you send:
100001 in binary, or 33 decimal, or 21 hex.

[Flecko]

Hi,
what is the format of a binary number in TMCL?
is "SGP 67,0,10001" setting GP67 to binary 10001 or to dec 10001?
Greetings Adrian

[B. Dwersteg (TRINAMIC)]

This would mean a decimal value. Please see chapter 7.7.2 in the TMCL reference manual for the possible number representations.

[Olav Kahlbaum (TRINAMIC)]

Always use decimal numbers. The only exception is the TMCL Assembler, where also hex numbers can be used (preceeded with a $ sign).