MrPLC Member
  • Content count

  • Joined

  • Last visited

Community Reputation

2 Neutral

About drx

  • Rank
  • Birthday 11/09/77

Profile Information

  • Gender Male
  • Location Paris
  • Country France
  1. Counting on WinCC Flexible

    Hi, HMI sure ain't recommended for computation, though, you still can use a VBscript for this kind of purpose if you don't consider your counter as critical for your system. Efficiency of your counter will depend on your net speed, the frequency of your bit's blink and the time it's held on. Most HMI are quite low, and PLCs have higher priorities than HMI com management, might even be the least of their concern (whenever they have some spare time). On my side, I sure wouldn't use this kind of trick if it took to go under 500ms at the very lowest for either frequency or signal duration. From my own experience, 2 seconds signals can be considered as reliable. Just to say it depends on what you wanna count. Regards.
  2. ST Syntax Error

    Hi, Ken's solution is OK, it should do the trick, you can just set the length out of the inner loop : SIZE(TimeStamp[0],0,Length); FOR Position2 := 0 TO Length-1 DO FOR Char := 0 TO 81 DO TimeStamp[Position2].Data[Char] := 0; END_FOR; TimeStamp[Position2].LEN := 0; END_FOR; Once is enough for every string.
  3. Hi, I think unity pro is the most actual software gathering all plcs exploitation from the Modicon range (quantum, premium...) it should do the trick.
  4. Strange values

    Hi, Well, if one is correct and not the other, my guess is the wrong value is corrupted somewhere in your program ie MB27 or MW28 could be used in another routine. I'm afraid you don't have much choice but try to cross-ref all the possible components of your DINT, including possible MW/MD on the previous bytes... MW25 could corrupt MD26, so would MD23,24,25... Could also be a problem with the endianess, but you would have it on both values... If you wanna be sure to avoid such a corruption, you oughta think about using a DB to strore those values and see if it gets better. Good luck.
  5. hi, Well, I never had to configure télémeca-siemens com but my guess is that it is the same thing on the other side, you should set it in the HW config in Simatic or wathever the soft you use. Might even be physical like dip switches or rotary selector on he card. I assume the ordrer is the same for every brand. The zero in 0.net.station should be your card index as you can have more than one card on the rack. You might have to check the data endianness. If my memory's good, premium are small endian while S300 are big endian.
  6. Hi, The IP is not to be set in the instruction but in the hardware configuration, the READ/WRITE_VAR takes the node address for argument. In the hardware config, you should configure an IP adress corresponding to a node, then the ETY will do the job regarding the IP. if your distant plc has the node address net.station then the instruction syntaxe should be : READ_VAR(ADR#0.net.station,'dataType',srcAdress,sizeOfArray,dstAdress:size,statusArray); Say I read distant %MW1000 to %MW 1010 and store it in local %MW1000 from the PLC modbus {1.17}: READ_VAR(ADR#0.1.17,'%MW',1000,11,%MW1000:11,%MW4000:4); Hope it helps...
  7. Hi, thanks for your concern... The software is ProWorx32. Quite used to PL7 Pro, the %System words were the firsts I looked for but unsuccessfully. I could find out which bit of which word means what but cannot find where this STAT function reads the values from... For instance in the dataWatch window I tried all the keys from the keyboard to see what could be available, and it would take nothing but the 0x, 1x, 3x, 4x and 60x registers and # for constants Having a life bit is something I thought about but I was trying to be sort of elegant, if the information is available why not use it ? Anyway, I don't like it, but I'll never be able to be sure my reporting program works for there is no way to give it a try, stopping these PLCs is just impossible... It's all about faith Whatever... Wish you the best for Christmas, have a nice time.
  8. Hello, I am actually adding PLC /network diagnostic on citect SCADA pages. So far, not much a problem. But after looking at the whole thing from above, I figured out a stupid thing. On these pages, I display the RUN status bit (and others) of the plcs, to do so, I use the STAT function and then read the register 4x in which the status words were copied. But say, if the PLC is not running, the program ain't neither, the instruction is not executed, then the register is not updated, and I'll display that the plc is running all the same because the register will freeze as it was before the PLC stopped... Here is were I need help, I can't find how to access the STATUS register directly, I don't even have the slightest idea of where it could be, I first thought the few firsts 4x were dedicated to the system but seems like not... With some other Schneider PLC there are %SWxx, but really can't find it in these Quantum ones, and if I could directly read into them with the scada ? Been roaming here and there on the web but couldn't find any answer but to use the STAT function... Could I be the only one to realize this snake is eating its tail ? On the other hand, I'm not sure the PLC would answer the SCADA's data queries if not running... And wouldn't try for this PLC hasn't been stopped for years being important for the factory... Does anybody have a clue about that ? Thanks.
  9. citectSCADA Syntax

    Hi, I have a really simple problem to which I can't find the answer. I have to write a CICODE function in which I need to modify some of the arguments given, I first wrote it the easy way (as for a PLC) with the guess that it wouldn't work... Well, it doesn't work All the documentation seems to have disapeared and all I could find is a PDF reference guide on the web that doesn't say much but the basics. Quite optimistic, I've tried to reference my argument both C and C++ style (pointer and alias) but the compiler obviously likes none. Though a few of the functions I saw till now are kind of copied/pasted using globals variables, I'm sure this should be possible, I just can't find what the syntax is... To be sure I made myself clear, I'd need the CICODE equivalent to : /***C like ***/ void foo(int* x) { *x+=5; } called by : foo(&myVariable); /*** C++ like ***/ void foo(int& x) { x+=5; } called by : foo(myVariable); I figured out I could send the variable name as string and use the readTag / writeTag functions but seems not very...efficient. Would be great if any one could tell me how to do that. Cheers.
  10. Project help

    Hi, Well... PLCs are industrial stuff and are meant to be used as. You can sure use one for training purpose but you also need the stuff that comes with such as motors, sensors or whatever. PLCs cannot play tic tac toe efficiently, sorry for you. I don't have much idea about a project you could do with a PLC and nothing behind it. Would have been nice to have a little machine doing something, but without mechanics... As for lighting leds, using a PLC to do what can be done with a toys'r'us "my first electronic set"...There would be no point and I'm not sure it would impress anyone. You could probably combine a PLC and PCB for a 2 or 3 lifts simulation. You would have the lifts logic in the PLC and the PCB to display the simulation. What would it be ? Do you have to create one or using PIC / Arduino would be fine ?
  11. Hi, For sure I wouldn't waste my time tryin to code a full application with C, and using a computer is even worse, most of the time, a multitask CPU would be doing anything but running your program. At least not any computer with an OS such as windows. As a reminder, the basic question was about limitations. Yes C can do a LOT MORE than a plc can, if it does the same, it will do it faster and more efficiently (depends on the PLC though). But it has to be dedicated to one particuliar task like creating your own electronic with micro-controler. If for any reason you need a task to be perform at high rate, what PLC could probably do it ? You're going to buy some dedicated electronic that will be likely programmed with C... Nonetheless, PLC should ALWAYS keep a low-level langage in their langage set, because PLCs have more and more to do and you don't wanna waste time on easy things that have become complicated because of high level langage. I have here a Logix 5562S that need to manage 6 physical axis and 3 virtuals (Sercos Kinetix 6k) and I expect it to spend its time controlling my axes, not converting gray to binary. I use the gray to bin exemple because it is the classical low level fast thing to do that becomes long and slow on a high level langage. Think about it, what would you do if you were asked to do the math on such a PLC ? Would you loop the bit-to-next bit XOR the way you do it with paper and pencil, like : Binary.15 := Gray.15; for i:=14 to 0 by -1 do Binary.[i] := Binary.[i+1] XOR Gray.[i]; end_for; when it should takes about 6 lines of UC native instructions, all the math in the stack, would take no more than 10 UC clock ticks to be done. This loop, for only one value of I is already slower than that. And why is that ? Only because you don't have the instruction performing a bitwise shift even though it is part of any RISC instruction set ? Say with LIST programmed S7 this conversion is likely to be at least 20 times faster than the loop thing : when one is already back to controlling the axis, the other one is still calculating a ridiculous conversion... For sure, most of the time the loop will do the job all the same, just to say that when it comes to be critical, some PLC just can't do it...for now. I'm not saying PLC are not good at doing thing, be sure I bless Rockwell everyday for having this stuff, (almost) plug'n'play, doing all the maths by itself etc... And I sure don't wanna spend my next 2 years developping in C what just took me 1 month. Div_by_zero said about C : "there are almost no limitation." I wouldn't say "almost", there are NO limitation : If a system can do something, you can have it done with C. I Use to compare things to cars, you can buy a fancy 4x4, good looking, comfortable, automatic shift, GPS, Satellite radio, fridge, cups holder, TV sets and DVD player for the children, A/C, fully equiped : most of the time you might go where a sedan wouldn't, but you sure ain't gonna follow a NIVA where it goes, because it is unconfortable, doesn't have electronic stuff, is ugly, but it was build for one purpose only : go anywhere. At last, TConnolly is just right : "use the tools that are best designed for the job" : and sometimes, embbeded C/C++ is this tool. Edit : I've just seen this topic, the guy thinking he might have a PLC playing tic tac toe. I had not think about it, but here is something PLC just can't do. If you need some decision-making, in most cases you'll need recursivity, even for a very basic min-max algorithm (that is likely to be used for a tic tac toe). And I know not any PLC being able to perform recursive functions. The only option left will be to precalculate (that means you and me) all the configurations possibles and program it. That is something that will take hours to program for a PLC versus 10 mins with C. Obviously, I was never asked by my customers to have a tic-tac-toe or chess playing machine, but decision making will be something done either by a computer or a dedicated chip.
  12. Hi, Beeing myself a hobbie C programmer and an PLC programmer for feeding purposes I use to prefer from far the PLC structured text programming than the ladder one. First of all because I've never considered ladder programming as beeing algorithme able, it is only about sorting out the result of simple logic equations. But is for sure quickly understandable. The other point is that a ladder routine cannot be considered predictive as it has to be completely evaluated as reverse instructions may occur by the end of the lines (ie : the NOT in siemens S7 reversing the previous evaluation) when a structured text / ASM is predictive by definition. Just to say that the result of A and B is likely to be evaluated twice faster in structured text than in ladder. If the plc software provides its own C-like langage, there would be no point using C, but C is still the lowest level langage available (apart from ASM) and that makes it the most powerful, as long as you know how/what to do. The other advantage of C is the fact that it is now an old langage though still in the TOP 2 most used, and we can consider that compilers on which programmers have been working for 30 years or so can produce an optimized final code. We have a problem with PLC compared to computers, execution time is something we really care about, any langage producing garbage and/or unefficient code is as much CPU ticks lost. Not long ago, on this topic I explained how the Siemens LIST (ASM-like) programming was fast and powerful, though programming needs more skills than ladder : no question about that ! There is one thing I'm certain of, as PLC will become more and more powerful, nothing will change because they will suffer from the Wirth's law for exactly the same reason our computers do. Higher level langage, lazy and/or hurried programmers leading to garbage code and slowing uselessly the UC down as they get faster in execution. Especially as our PLC are not only simple logical testers any-more and can have to handle (more or less) complex algorithms I'm sure most of us have already seen dang complicated equations that could be simply done 10 times faster with at least half the lines. Really, the langage is only a small part of the job, you can use anyone, if you don't know what you're doing, well, the result ain't worth a s*** all the same. Regards.
  13. Hi, The ladder would do, the one thing is, as I said in my first message, if loosing 1 cpu cycle is allowed or not. Say you get into the ladder routine beeing on Position 3, with enable4=OFF and enable1=ON : you would expect ouput1 to be ON when leaving the routine as it is obviously the next one on the "activation list" But when you'll reach the end of the routine, output3 and output4 will be OFF as they should, but output1 will be OFF : It will take to wait until next CPU cycle to be calculated correctly. It's just a detail, it might not be important for your application, if so, the ladder should do the job just the same, and for sure, can be a bit more comprehensive than a structured text algorithme. But this one guarantees you loop-checked everything from next to previous, and in the conditions above, you will reach the end of routine with output1 =ON as it should. As for the code I wrote, it's just an general algo, I'm sorry if the syntaxe is not exactly correct like it should, but I write code in many langages and come to mix them sometimes. Good luck.
  14. Hi, Might not be the most efficient but a counter as being a sequence number mould do. If you do it with ladder, you will probably loose 1 CPU cycle going from 4 to 1. Writting a function seems the most efficient to me but would work on arrays to be short... Say, if you call the function on the trigger RE : output[count] :=0; //unlatch actual output watchDog:=0; //used to avoid endless loop REPEAT IF count<3 then count :=count+1;//increase up to 3 ELSE count:=0 //or back to zero END_IF; loopWatch:=loopWatch+1; //loop counter if all condition switches are off (might happen) output[count] :=condition[count];//output equals its associated condition; UNTIL (output[count] or (watchDog>=4)) // until an output has been set, or none END_REPEAT; Chek the syntaxe, I just wrote this like that, it's the idea, not the solution. count should be persistant to 'survive' from one function call to another. That is if you copy your switches into an array and outputs from another one. Hope it helped.
  15. Citect network setting

    Hi, I'm afraid I understand what you wanna do. Man, if you think you can do your own config by messing with the .ini files, you're far from the truth. You can either look in the documentation and configure your project manually. Start with the wizzard, it is usually efficient enough and if it is not, 90% of the job will be done and the 10% left will need fine tuning...