 |
Trinamic Discussion Groups
For quick support, please browse or search the forum!
|
| Print this topic :: View previous topic :: View next topic |
| Author |
Message |
anupmm
User
Joined: 10 May 2007
Posts: 2
|
 Posted: Thu May 10, 2007 12:27 pm Post subject: Completion notification to PC for stand-alone program |
 |
|
Hello,
We are executing a stand alone program on the TMCM 303 board. After the "stop" command in this mode we want to continue working in the direct mode. But how do we get a notification of the same?
// Code // This code is supposed to rotate a motor 5 times
SGP 0, 2, 5
LOOP:
MVP REL, 2, 12800
WAIT POS, 2, 0
GGP 0, 2
CALC SUB, 1
AGP 0, 2
GGP 0, 2
COMP 0
JC GT, LOOP
STOP
We tried using "Get Global Parameter" from the direct mode to read the variable stored at position zero in bank 2 and wait until it goes to zero.
This at times suceeds and at time gives a timeout error. We think this is because the accumulator memory gets overwritten.
Please suggest a solution to this.
Regards,
Anup M M |
|
| Back to top |
|
 |
Andrew
Master
Joined: 06 Nov 2006
Posts: 258
Location: Europe
|
| Posted: Thu May 10, 2007 1:15 pm Post subject: Notification function UF1: active communication |
|
|
There's an undocumented custom function UF1 in latest versions of TMCL Firmware.
I call it "Active Communication".
It instructs a module to send one reply, without being asked.
As I explain below, you can't use this function right away. The TMCL-IDE does not allow to deal with it at all.
I have built my own develeopment environment. It is called TMCM-DLL:
http://www.trinamic.com/ttdg/viewtopic.php?t=30
As the name suggests, the TMCM-DLL has a DLL interface. So you can connect to it programmatically, and integrate it into your own computer software. Its develeopment environment allows quick prototyping of direct mode and standalone mode programs. You can prototype programs even if you design them not for a computer, but for some other processor.
I explain the UF1 below.
| asaf wrote: | Subject: "TMCL hand shaking with PC"
How does the PC knowes that motion has ended?
Is there any event from the TMCM controller ? |
| Olav wrote: | The TMCM module normally does not send events.
The easiest way is to poll the actual speed or the actual position, using GAP 3 resp. GAP 1 and to check if speed has reached zero or the desired end position has been reached. |
There is a task which I am working on now. I birefly mentioned it here:
http://www.trinamic.com/ttdg/viewtopic.php?t=117
Related to this task I asked Trinamic to add a standalone command, which I call "Active Communication".
Trinamic made such function.
It is present in firmwares since 3.25, I think. But it had a bug.
Firmaware 3.28 has fhis function working more or less well.
Curently "Active Communication" is implemented as a user function:
UF1 Type, Motor, Value
Value is sent to the computer. Type and Motor are ignored.
The Status field of the reply, which UF1 sends, is 129 - identifying a reply from "Active Communication" UF1.
It still has a bug.
The function works well in standalone mode.
The bug manifests itself only in direct mode, as follows.
It sends 2 reply messages, instead of one.
The first reply is the reply from UF1 proper. The second - is a repeat of a reply given to the command a module received immediately before the current UF1 command.
2 replies confuse TMCL-IDE. After you use a UF1 in direct mode, it continues to give a previous reply to a current command. Replies are shifted by 1 command ever since, until you reset the software, or discard the erroneous second reply otherwise.
You read the second reply of UF1 by sending one more command. If you use a command other than UF1, you would expect 1 reply. But the TMCL-IDE would postpone the reply till the next command, and rather return the mentioned second reply from UF1.
The reply you expect to the current command would actually return with the next command. The mismatch would continue till you reset TMCL-IDE software.
I think this command should be extended to send not only a fixed Value, but also an accumulator, or any parameter from TMCM memory.
But the fact is, that this function already exists.
It is possible that it might not be included with some firmwares.
I suggest you download the latest firmware from Trinamic, and try the UF1 in direct mode. If you get 2 replies, as I mention above, then "Active Communication" is present.
As I mentioned, in standalone mode there's no problem of second (erroneous) reply. But still there's a problem. Because TMCL-IDE does not expect "Active Communication" - it does not expect the unsolicited replies.
You won't be able to use "Active Communication" with the current TMCL-IDE. Because TMCL-IDE is not deisgned to use replies, perform actions on them, or perform any action in general for automation. The TMCL-IDE simply sends commands passively.
Also, as I mentioned above, "Active Communication" confuses the TMCL-IDE, if you test the function in direct mode. It would work better in standalone mode. But it would still confuse the TMCL-IDE.
You need to write your own software, or use mine, described here:
http://www.trinamic.com/ttdg/viewtopic.php?t=30
It is called TMCM-DLL.
It is designed to deal with commands UF1 and #138. It is also an active sofware - it can allow you control the program flow. In other words, it allows programming directly within it. It also allows programmatic control of itself via a DLL interface. So essentially you can incorporate into your own code this same code, which you used in prototyping. You may even prototype for systems other than a PC.
To avoid corruption of Accumulator, while mixing direct and standalone modes, you need to upload into the module the latest FirmWare.
We discus corruption of accumulator here:
http://www.trinamic.com/ttdg/viewtopic.php?t=360&highlight=accumulator
http://www.trinamic.com/ttdg/viewtopic.php?t=53&highlight=accumulator
Latest FrimWare prevents most direct cmmands from modifying the accumulator, even when standalone program is not running in the module.
_________________
Distributor of Trinamic
Our TMCM-DLL is here (not free): http://www.trinamic.com/ttdg/viewtopic.php?t=30 | Power supplies: http://www.trinamic.com/ttdg/viewtopic.php?t=394
On request: System integration services, custom programming, mechanics,etc
Last edited by Andrew on Sat Dec 01, 2007 6:32 pm; edited 7 times in total |
|
| Back to top |
|
|
Olav Kahlbaum (TRINAMIC)
TRINAMIC master
Joined: 11 Aug 2006
Posts: 950
|
| Posted: Fri May 11, 2007 8:11 am Post subject: |
|
|
| The problem of corrupting the accu when mixing direct mode and stand-alone mode has been corrected in since version 2.49 of the firmware came out. So it is not present any more for some years now (in all 3.xx and 6.xx versions). |
|
| Back to top |
|
|
Thomas Rupp
User
Joined: 23 Nov 2006
Posts: 6
Location: Germany (Düsseldorf)
|
| Posted: Wed May 30, 2007 12:27 pm Post subject: Event that the motor has reached his position. |
|
|
Hello Experts,
What function should I use if I what to be notified that the motor has reached his position in direct mode?
This:
http://www.trinamic.com/ttdg/viewtopic.php?t=480#1617
Or the UF1 command?
What will be supported in future?
Greetings
Thomas  |
|
| Back to top |
|
|
Olav Kahlbaum (TRINAMIC)
TRINAMIC master
Joined: 11 Aug 2006
Posts: 950
|
| Posted: Tue Jun 05, 2007 8:09 am Post subject: |
|
|
| Yes, to get a notification that the motor has reached the position in direct mode please use the "delayed reply" function (that is described in the thread you have mentioned) and not the UF1 function (as this has not got anything to do with the motors itself and only works in stand alone mode). |
|
| Back to top |
|
|
Andrew
Master
Joined: 06 Nov 2006
Posts: 258
Location: Europe
|
| Posted: Wed Jun 06, 2007 1:32 am Post subject: Synchronising logically: event notification in TMCL |
|
|
| schjue wrote: | wir setzen momentan das TMCM-101-Board ein um mehrere Schrittmotoren anzusteuern. Wie wir aus der Dokumentation entnehmen, ist es nicht möglich, das Ende einer Move-Bewegung als Event zu erhalten. Wir müssen stets abschätzen, wie lange die Bewegung dauern wird und dann mit hohem Performance-Aufwand ständig nachfragen, ob die aktuelle Position der Zielposition entspricht.
Welchen Aufwand müssten sie/wir betreiben, um zu einer Event-basierten Lösung zu gelangen? Unsere Windows-Applikation wurde mit C++ erstellt und greift den CAN-Bus über einen Peak-USB-Adapter ab. |
Olav Kahlbaum
(Trinamic) wrote: | seit der Firmware-Version 6.24 (für TMCM-101/102/610/611/612) bzw. 3.15 (für TMCM-110/111/300/301/302/303/310) gibt es jetzt so etwas, es ist nur noch nicht dokumentiert, da es bisher so eine Art experimentellen Status hatte (kommt aber demnächst auch in die Dokumentation).
Der Befehl dazu (genannt "request delayed reply") hat den Code 138. Die Parameter "Type" und "Motor" werden immer auf 0 gesetzt, und der "Value"-Parameter enthält einen Bitmaske. Hier sind nur die Bits 0..5 relevant (bzw. beim TMCM-101 natürlich nur Bit 0). Jedes Bit steht für den jeweiligen Motor.
Nachdem dieser Befehl gesendet wurde, wird zunächst die normale Bestätigung gesendet. Nachdem alle Motoren, deren Bits auf 1 gesetzt waren, ihre Zielpositionen erreicht haben, wird ein weiteres Antworttelegramm (eben die "delayed reply") gesendet. Der Statuscode ist dort auf 128 gesetzt, und das "Value"-Feld enthält dieselbe Bitmaske wie im Befehl.
Funktionieren sollte das mit jedem beliebigen CAN-Adapter (es geht auch mit RS232 und RS485, wobei man bei RS485 natürlich dann aufpassen muß, daß es nicht zu einer Kollision auf dem Bus kommt).
Der Befehl hat keinen Mnemonic, da dessen Verwendung nur im Direktmodus sinnvoll ist (in TMCL-Programmen kann man hier ja WAIT POS verwenden, was aber wiederum im Direktmodus nicht geht).
Ich denke, das wir diesen Thread eventuell in das TMCL-Forum verlagern werden. |
| Andrew wrote: | Translation:
Since FirmWare 6.24 and 3.15 there's a new command #138 (was reserved previously).
Fields Type and Motor are ignored. Set them always to zero.
Value is a bit mask. Each bit stands for the respective motor. Bits 0 to 5 are only valid. For modules of 1, or 3 axes, only bit 0, or 0 to 2 are valid, naturaly.
When a module receives this instruction, it sends a normal confirmation. After all masked motors achieve their target, a further answer telegram ("delayed reply") is sent. The status code of the telegram - 128. The "Value" field contains the same mask as in the original instruction.
To function should work with any interface (CAN, RS232, 485, etc.) Just watch out for collisions of data.
The instruction does not have Mnemonic. Because its use is meaningful in the direct mode only. In TMCL programs one can use WAIT POS, which does not go however again in the direct mode. |
My comment to the translation above: a command #138 would be quite useful in direct mode as well. I can use it without a mnemonic anyway. Because I can send binary data to module.
Another command for notification is explained in my post above.
In total there are 2 commands, which send independent (active) notification:
UF1 - "Active Communication"
#138 - "Delayed reply" (Or "Notify on arrival")
My guess is that both UF1 and the new command #138 will be supported in the future. At least that's what was the original agreement for UF1 expressed to me by Trinamic.
Currently it is a command UF1 (command #65).
In the future it might be assigned another code, when it is moves into mainstream TMCL FirmWare. Till then it remains an experimental function UF1.
UF1 works both in standalone, and direct mode. Though it is most meaningful only in standalone.
In direct mode it might be meaningful in troubleshooting, or stepping through commands without actually downloading them... Thus sparing EEPROM from wear.
(See on wearing EEPROM here:
http://www.trinamic.com/ttdg/viewtopic.php?t=117&highlight=wear+eeprom)
UF1 is merely a notification command. It spares the user from a need to poll a module. "Active Communication" versus polling".
It does not check for position, or anythining else. It just gets executed. It notifies computer of completion of some code.
You may use it in standalone loops of code for detection of various conditions, including detection of arrival.
The difference between commands UF1 and #138 is also as I describe below.
You can place UF1 anywhere in code at your convenience, regardless of motion. It is versatile - can be used for detection of any condition in your code, not just position.
But for detection of arrival to position it needs a few extra commands in a loop, which prolong execution.
#138 is not flexible, or versatile. It is tied rigidly to motion. Its advantage might be a decreased time of execution of an internal loop of code of detection.
Disadvantage: it might detect arrival only in position mode (when motor arrives, and acceleration is zero). It would detect arrival unreliably, if motor passes the target without stopping. Just as unreliably as a command WAIT POS does. Though I did not test it. I just speculate.
I also did not test whether this is the case. Whether indeed command #138 has a loop of 1 command (0.38-0.41ms). Or its loop has the same duration as 4 commands (about 1.6ms) that would be required with UF1 for detection of position.
See another thread on duration of commands:
http://www.trinamic.com/ttdg/viewtopic.php?t=53&highlight=duration
An open question about #138 remains whether it blocks execution, like WAIT? |
|
| Back to top |
|
|
Andrew
Master
Joined: 06 Nov 2006
Posts: 258
Location: Europe
|
| Posted: Wed Jun 06, 2007 1:11 pm Post subject: Collisions of active notifications over communication line |
|
|
| jimgeorge wrote: | | Thanks for the info, but this won't work in my application, since I'm using RS485 to talk to the motor. The RS485 PC interface will not expect the bus to be "turned around", so I'm not sure if it will relay the data. Also, I may be communicating with other motors or devices. In any event, my host-side software polls the motor for position updates anyway, so this function can be wrapped up in there. |
| jimgeorge wrote: | | ... The RS485 PC interface will not expect the bus to be "turned around" ... |
Perhaps you mean that there could be collisions of packets. I agree. You just would need to investigate how the modules and computer handle collisions.
I just will note that each packet from each module has an identification byte - address of the module.
Also each has a status byte. So you will always be able to sort the received packets, and infer their meaning.
Olav Kahlbaum
(TRINAMIC) wrote: | Yes, active communication can lead to bus contention when having more than one module connected via RS485 (which leads to loss or corruption of data bytes).
With CAN bus, this can not happen, as the CAN controllers handle this automatically, and no data can get lost. |
I remember RS485 also has some means, perhaps a separate wire, which reserves the line for transmission just before any module or computer gets ready to transmit.
If I am wrong, then you can always organize such wire with I/O pins (via GIO/SIO commands). |
|
| Back to top |
|
|
Andrew
Master
Joined: 06 Nov 2006
Posts: 258
Location: Europe
|
| Posted: Sun Jul 01, 2007 9:33 pm Post subject: Sample application for UF1 and #138 notification commands |
|
|
By the way, here is a trivial example from one user how he could use the two commands UF1, and #138.
Instead of polling, one could simply wait for a packet from one of these commands.
| gfim wrote: | We are developing an application which use a TMCM-610 running a standalone program. However, we would like to dynamically specify parameters for the program from a PC and have some program status reported back to the PC. The current plan is to use global parameters in Bank 2 for the communication. So it would work like this:
- download TMCL program into TMCM-610,
- set auto start mode to 1,
- power cycle module,
- module starts executing.
Then
- TMCL program polls a Bank 2 global parameter using command GGP,
- PC sets the parameter to a value using SGP over the serial port,
- when the TMCL program sees the parameter is set, it carries out some commands accordingly,
- when the commands are complete, the TMCL program sets another global parameter to some status value using SGP,
- PC is polling this second global parameter using GGP over the serial port,
- when it sees the value of this parameter change, it knows the program has completed its task.
Does this sound feasible? Are there any locking/access restrictions on the two parameter locations (i.e. concurrency issues)? I presume I could use undocumented custom function UF1 (as described in this thread) instead of the PC polling for the return status? |
| B. Dwersteg (TRINAMIC) wrote: | | This looks feasible and should work this way! |
|
|
| Back to top |
|
|
roman
User
Joined: 27 Oct 2006
Posts: 12
Location: Presov, Slovakia
|
| Posted: Thu Jul 12, 2007 9:10 am Post subject: |
|
|
| Olav Kahlbaum (TRINAMIC) wrote: | | Yes, to get a notification that the motor has reached the position in direct mode please use the "delayed reply" function (that is described in the thread you have mentioned) and not the UF1 function (as this has not got anything to do with the motors itself and only works in stand alone mode). |
I am really surprised that there is not nowhere described more clearly such crucial task as detection of position reached or motor stop. However on the web you have the document "TMCL Reference and Programming Manual" with version: 2.18 from November 15th, 2006. There is no mention about "delayed reply" function nor UF1. Could you be so kind and provide some more detailed information how could be used "delayed reply" function to detect mentioned events, thank you. |
|
| Back to top |
|
|
roman
User
Joined: 27 Oct 2006
Posts: 12
Location: Presov, Slovakia
|
| Posted: Thu Jul 12, 2007 9:28 am Post subject: |
|
|
| My another question is regarding the Advanced axis parameters and interrupt flags (139). What is the length of bits? 8 or 16 bits? TMC428 datasheet says that 8. Is it possible to use these bits for detection position reached and motor stop? If yes, could you write me few words about this, how should I do that? Thanks. |
|
| Back to top |
|
|
roman
User
Joined: 27 Oct 2006
Posts: 12
Location: Presov, Slovakia
|
| Posted: Thu Jul 12, 2007 9:37 am Post subject: |
|
|
Can I use axis parameter Actual speed to detect if motor has stopped? I have your TMCM-110-42 and TMC428 datasheet says reagarding the v_actual that | Quote: | | Because of this, the actual velocity should not be used to detect a stop of a stepper motor. |
|
|
| Back to top |
|
|
Andrew
Master
Joined: 06 Nov 2006
Posts: 258
Location: Europe
|
| Posted: Thu Jul 12, 2007 2:00 pm Post subject: UF1 and #138 are already explained. Detection of position... |
|
|
| roman wrote: | | I am really surprised that there is not nowhere described more clearly such crucial task as detection of position reached or motor stop. |
You are not quite right. Only commands #138 and UF1 are not in manuals. They are quite new.
UF1 was introduced in year 2005, as an experimental quick fix.
#138 was introduced maybe in year 2007.
I believe the description of these commands is complete on this thread. There is nothing extra to say. Use it. Later perhaps it will be added to manuals.
The detection of arrival can still be done with command loops, and checking routines (programming in standalone mode).
For example using axis parameter #8 "target reached".
Using these is especially necessary, if you favour the command UF1, because it does no detection of its own.
For programming techniques please see this thread:
http://www.trinamic.com/ttdg/viewtopic.php?t=579
Another thread explains why sometimes a detection of arrival with GAP 8 may not always work in velocity mode:
http://www.trinamic.com/ttdg/viewtopic.php?t=600
"Arrival" needs some conditions to be met.
| roman wrote: | | Advanced axis parameters and interrupt flags (139). What is the length of bits? 8 or 16 bits? TMC428 datasheet says that 8. |
This parameter is in tandem with parameter #152.
Both occupy 8 bits. Parameter #139 occupies 8 lower bits. Parameter #152 - 8 higher bits.
I forgot how they display. Perhaps, when you display either of these parameters they display all 16bits - combining both parameters. This behaviour is common to a few other parameters, with which you can set several parameters at once. Perhaps by setting higher bits of parameter #139 you are actually seting parameter #152.
| roman wrote: | | Is it possible to use these bits for detection position reached and motor stop? |
Maybe. Read chapter 8.13 of TMC428, and experiment. Anyway, these parameters are for advanced users. So, do your best.
Less curious users simply use axis parameters, like #8, and specialized TMCL commands.
Related axis parameters are:
#8, #10, #11, #12, #13, #141, #147-#150;
perhaps a global parameter #78 Poll interval";
and a reference search command RFS.
_________________
Distributor of Trinamic
Our TMCM-DLL is here (not free): http://www.trinamic.com/ttdg/viewtopic.php?t=30 | Power supplies: http://www.trinamic.com/ttdg/viewtopic.php?t=394
On request: System integration services, custom programming, mechanics,etc |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Impressum
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
