jotlake

Hi, We are using quite some of the older and slower 60MHz PMAC-PC boards where the product processing application has some lengthy background PLC routines and continuously data-gathering upload (list gather commands) through the host interface during the production process. During its 25 seconds product processing cycle, the running motion program is using following mode about 150 times with RAPID moves in-between. Due to the background PLC processing and gather upload commands, the PMATCH commands after the following mode can take up to 25 milliseconds, and to speed-up the production process I want to use a custom and more efficient alternative to PMATCH. The motion program has just a single X-axis with 1 motor, and writing directly into the CS1 X-axis target position register (m165_Cs1XaxisTargetPos->L:$081F) to manually sync it with the commanded+master motor position seems to do the same as the PMATCH command (and much faster). I did a test with a motor and our production process in simulation mode (not on a real machine yet), and everything seems working fine with an almost 10% faster cycle time. Does anyone have experience using such a custom and faster alternative for calling PMATCH from a motion program? Or is the PMATCH command doing more than just syncing the motor position(s) to the axis position(s)? Thanks and regards, Jan

Hi, I want to make practical use of the "PMAC Interrupt Packet" mechanism as described in the "Turbo PMAC Ethernet Protocol.pdf" manual (application note). I am using a TurboClipper board for software development and testing, while our production machines are using Brick controllers. Although we don't have the MODBUS option (since we don't use MODBUS), I successfully created an interrupt socket using I67. i67_ModbusTcpBufferStartAddress=$10700 ; Start address socket setup buffer WL:$10700,$100000000000 ; Enable socket 0 for TCP ascii WL:$10703,$200000000000 ; Enable socket 1 for interrupt WL:$10706,$100000000000 ; Enable socket 2 for TCP ascii WL:$10709,$100000000000 ; Enable socket 3 for TCP ascii In my host application, I can open the additional interrupt socket on port 1026, and can send an VR_PMAC_INTRSTRING message to the normal port 1025 (with the "P0..10" example). If I don't setup the interrupt socket with I67, I can't open the socket on port 1026, so the whole mechanism with the interrupt socket seems to work (although we don't have the MODBUS option). However, the manual does not describe how to active or trigger an interrupt to the Ethernet controller, and I don't receive any data on the interrupt socket. The manual only describes it as "an interrupt generated to the Ethernet microcontroller from the PMAC motion controller", and "Background PLC writes via a M-variable pointer to cause an interrupt to the Ethernet processor". Therefore I have 2 questions: - can anyone clarify how to generate an interrupt to the on-board Ethernet controller on a TurboClipper board and Brick controller? - or is the MODBUS option really required to make use of the interrupt socket? Thanks and regards, Jan

Thanks for your reply. Off topic: I don't think 'LIST GATHER' upload of gathered data is more efficient, since basically it gives the same data as 'RHL' commands that uploads blocks of data. We developed our own version of PmacPlot with a more advanced gather data handling, like 'realtime' data upload while gathering, support for cyclic gather-buffer handling and of uploading of 'old' gather data while a new gathering has already started (but did not overwrite the unread data yet). The standard PmacPlot32Pro2 does not support this and can't handle configurations with multiple simultanuous TCP/IP connections the PMAC without blocking other sockets (or at least some years ago could not). On topic: Use the of ASCII-based data upload though the standard command interface requires too much bandwidth for our new data gathering requirements, at the moment we don't have the DPRAM option on our Ethernet Brick. In addition gathering data must be 'pulled' from the PMAC instead of a streaming way initiated by the PMAC, and therefore we want to use EtherCAT-slave option to publish the data realtime (the EtherCAT bandwidth itself should be sufficient for that). Are you aware of any (standard PMAC, non PowerPMAC) applications that use a similar approach like this? At this moment I don't have enough experience with EtherCAT and the Hilscher ComX Module option for the BrickController (that we didn't order yet) to overlook all possible limitations and pitfalls, and how much effort is needed to get it working with the Beckhoff scope tools. Therefore I'm searching for feedback if this EtherCAT solution is useful way for high-speed 'realtime' data gathering, and I hope DT people or other forum users can guide us with that before we order and setup a prototype environment. Jan

Hi, Since the upload bandwidth of PMAC gathering data is limited using the standard communication interface with "RHL" memory commands, we want to extend an existing machine based on a TurboPMAC Brick Controller with an EtherCAT interface by using the 'EtherCAT Slave' fieldbus option (ACC72EX based solution). The product handling part of the machine (a standard PLC based environment) already has EtherCAT as the main I/O fieldbus. The idea is to make the Brick an EtherCAT slave and to publish the required gathering items 'realtime' on the EtherCAT bus using PLCC0 and the DPRAM interface of the ACC72EX module. The standard EtherCAT scope tools (by Beckhoff) could then be used for the data gathering and visualization. Is this a feasible use-case of the EtherCAT option on the Brick controller? And if so, would the bandwidth be enough for a 1 kHz update rate for about 10 gather items? Regards, Jan van der Meer

I already wrote a small C++ host program using the RP:$xxxx commands to determine the loaded and running PLCC's, similar to the PLCC status dialog in PEWIN32PRO2. A solution without extra administration inside PLCC routines itself would be preferable, to minimize the risk with implementation errors using our general-purpose framework to start and stop PLCC routines (based on production recipes). For example, enabling a PLCC twice will always force it to restart a the beginning, while an already running PLCC could be waiting somewhere in a while loop half way. Do you know a way (i.e. with M-variables) to access instruction/program memory by a PLC or PLCC program, like the RP:$xxxx command does?

Thanks for the example, it looks well documented so it will probably be a good start to add detection for the line number and maybe some optimization for a single CS. A standalone way to determine the program and line number has a preference above adding line debug variables into the code, since that makes it more difficult to analyze and debug existing and running applications without modifying the (production released) source code. Some time ago I wrote a Notepad++ plugin that visually tracks the current program and line number, using the 'PC' command that highlights the current line. This looks pretty cool, but is off course not really realtime (but still 10 to 20 times per second) and difficult to analyze offline. Therefore I prefer to find a 'semi realtime' way using a PLC/PLCC combined with the normal data gathering, to match the line numbers to the axis positions. I will let you know when I have figured that out, but I don't know when I will find the time to do that (since it does not have a high priority).

Hello, For our framework and advanced debugging, we would like to programmatically monitor which actual CS program is running and in which line, like the PC/PE commands can report. If a PLC or PLCC program can detect this, preferably including the call stack like PC/PE commands, we can include this in a gathering setup for tracing which and where a CS program is running. In CS1 status range X:$2000 to X:$20FF, I can see some activity around X:$20E4 that seems to be related to the the active running program, but I can't find any information that describes how to interprete these (internal) CS status registers. - Is there a way to programmatically detect the actual "Program Counter" or "Program Execution Pointer" of a running CS program? Thanks and regards, Jan

Hello, For our recipe-based applications, it would be nice to programmatically detect (within a PMAC application) which PLCC routines are running, so they can be started and stopped gracefully when required. For standard non-compiled PLC routines the running status can be checked using the Y:$3100-$311F memory range, but for PLCC routines this is not described in the SRM manual. When monitoring the data traffic for PEWIN32PRO2, I can see it uses some RP$50000 to RP$500xx program memory commands (for a TurboPmac) to determine which PLCC routines are loaded and running. The RP$xxxx commands are not described in the SRM, and there is also no description how to use an M variable to access P memory. I found a work-around using the COMMAND "RP$xxxx" trick and reading the ASCII command response buffer, but this is very time consuming and not flexible. - Is there a programmatic way to determine the PLCC running status, i.e. through X/Y status registers? - If not, is there a direct way to programmatically access program memory data like a RP$xxxx command does, for example with a M-var definition? Thanks and regards, Jan