gregaxisne.com Posted August 30 Share Posted August 30 Are CMD's commands processed through the GPASCII thread, and is there an established communications buffer size limit / rate for issuing CMD commands from a plc on a quad core? Quote Link to comment Share on other sites More sharing options...
MoMo Posted August 30 Share Posted August 30 (edited) 16 minutes ago, gregaxisne.com said: Are CMD's commands processed through the GPASCII thread, and is there an established communications buffer size limit / rate for issuing CMD commands from a plc on a quad core? Yes the CMD instruction will send the string to the gpascii thread. The CMD instruction is indeed cached, so sending content by using the CMD instruction in the PLC does not guarantee immediate execution. You can use the following program in the PLC to ensure that the contents in cmd are completely executed before executing subsequent programs. Ldata.CmdStatus = 1; cmd "&1 delete lookahead" cmd "&1 #4->100C" cmd "&1 define lookahead 10000" sendallcmds; do { }; while (Ldata.CmdStatus == 1); // Will change when command executed// Delete buffer// Assign new motor to C.S. 1// Redefine buffer// Wait for command buffer to empty// Loop quickly while waiting Edited August 30 by MoMo Quote Link to comment Share on other sites More sharing options...
gregaxisne.com Posted August 30 Author Share Posted August 30 Yes, that is understood and hasn't changed since Turbo, I'm trying to understand if there is a size or rate limit compared to Turbo. Quote Link to comment Share on other sites More sharing options...
MoMo Posted August 30 Share Posted August 30 Gpascii that I know can accept up to 8192 characters, but I'm not sure if cmd can also execute such long strings Quote Link to comment Share on other sites More sharing options...
gregaxisne.com Posted August 30 Author Share Posted August 30 Can I send 500 sequential CMD commands from either C or a PLC without any issue? Each line less than 20 characters? What is the limit? 1000, 5000? Quote Link to comment Share on other sites More sharing options...
MoMo Posted September 1 Share Posted September 1 Can you tell me what you want to do? I'm not sure about your application. Quote Link to comment Share on other sites More sharing options...
leandro.martins Posted September 2 Share Posted September 2 Sorry, I have answered before, but I have hidden the answer by mistake - I was confused this was a turbo or power question actually. In V2.6.1 Maintenance Release notes for the Power PMAC, it states Quote 1. Now reject command lines with over 7168 characters with ERR28. Previously could crash Power PMAC. However, on V2.7.1, I have already observed some limitation in sending more than 4095 characters via terminal. Tried to assign a very long array into P-variables, and from the 4095th character, the assignments didn't work. I'm not certain if that is a per command limitation, or related to the buffer size. Quote Link to comment Share on other sites More sharing options...
MoMo Posted September 2 Share Posted September 2 15 minutes ago, leandro.martins said: Sorry, I have answered before, but I have hidden the answer by mistake - I was confused this was a turbo or power question actually. In V2.6.1 Maintenance Release notes for the Power PMAC, it states However, on V2.7.1, I have already observed some limitation in sending more than 4095 characters via terminal. Tried to assign a very long array into P-variables, and from the 4095th character, the assignments didn't work. I'm not certain if that is a per command limitation, or related to the buffer size. I'm very sorry, I forgot the specific value, but the previous firmware did modify this part. In any case, if you have a lot of content, it is recommended to generate the file and then load it through gpascii Quote Link to comment Share on other sites More sharing options...
leandro.martins Posted September 2 Share Posted September 2 (edited) Actually, I was just trying to stress to find the limitation. We have an external application that polls some information at certain frequency via "gpascii -2". When a large amount of motors is defined, that polling message might get too big. Forgot to mention: that was observed on dual-core ARM cpu. 43 minutes ago, MoMo said: I'm very sorry, I forgot the specific value, but the previous firmware did modify this part. @MoMo What version exactly? Is that documented somewhere? Edited September 2 by leandro.martins Quote Link to comment Share on other sites More sharing options...
MoMo Posted September 2 Share Posted September 2 2 hours ago, leandro.martins said: Actually, I was just trying to stress to find the limitation. We have an external application that polls some information at certain frequency via "gpascii -2". When a large amount of motors is defined, that polling message might get too big. Forgot to mention: that was observed on dual-core ARM cpu. @MoMo What version exactly? Is that documented somewhere? I think you can try the new DART function in firmware version 2.8.1.0, which can realize binary data exchange, especially when the amount of data is large, the exchange speed is dozens of times faster than Gpascii 1 Quote Link to comment Share on other sites More sharing options...
leandro.martins Posted September 2 Share Posted September 2 Thanks @MoMo, good to hear about that. It might be pretty useful for a lot of applications. Do you have some release notes of the latest firmware versions, or an updated Software Reference Manual containing them? The files in the Omron website haven't been updated in a while. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.