SPD Instuction

[Goody]

I am about to write a program where in one part, I need to count pulses from a proxy. I shall be using input X0 and counter C235 (for High speed operation) I have lost my instruction manual and wanted to test the SPD instruction So I set up a test and the SPD wants to know from which input I will be counting. Now if I remember correctly, when using input X0 as a HSC - or counters C235- - - -> You must not use XO anywhere in the program. SPD would be handy for monitoring in one instruction., otherwise I shall just 'bake my own' solution. So does anyone know if its ligitemate to use SPD with X0 when the pulses will be a very high speed?

[panic mode]

Hello Goody, I didn't use this in years but here is the page. As far as I remember, you are spot on. as far as using SPD with high speed input, why not use C235? i remember reading somewhere that if you use high speed input, it should not be used as contact, but are you short of inputs? you could parallel another input to high speed input... Someone like Sergey may know this better. SPD.pdf COUNTERS.pdf

[Sergei Troizky]

You cannot use the same input for SPD and HSC. If you are ready to sacrifice another high-speed input- just split the signal for two inputs.

[Goody]

Thanks for that, it cleared it up. and FYI I am using a FX1N 60MR I didnt use it in the end I just sampled the counts and Dmov 'ed them over a short repeating timescale (pretty much what SPD does anyway) But one thing during commissioning/programming really ticked me off about mitsi plc's. And that is the use of high speed counters and programing online. If you are using C235 and want to use 'monitor/write mode, it just will not let you. I needed to fine tune timers and add extra code as the machine was running. Not a chance, everytime I go to write the changes I get warned I cannot write while C235 is sat there in the code. I had to write offline then wait while I could have the machine for 5 minutes to download the changed code. In the end I deleted the counter until I had finished alterations then put it back in as the last thing.

[panic mode]

ouch, that's bad. i guess i worked too little with FX and that is why i didn't quite understand some of the grudge some members have shown. i just tried to do some work with FX3U and FX2N and I was quite disappointed: - all code in single program file (cmon Mitsi, this is only one step from using punch cards for programming) - ethernet for FX2N - only good for programming. - no Profibus master for FX2N (well the manuals are all over internet but no hardware - just google for "FX2N-64DP-M") - i like to see "my" and "yours" clearly separated. i hate to see system configuration invading (not to mention fragmenting) MY user memory (M and D). create another table and call it whatever, put all hardare settings in there and for the love of god leave MY memory space just for ME. for example all the system bits are in the M8000 area (invasion), D8000 (invasion and fragmenting) and now ethernet card for FX2N expects configuration to be at D1000 - but then I saw that this is only for first connection, settings for others are in D2000, D3000, D4000 etc. someone should be fired (and punished) for this. what were they thinking, couldn't they at least pack it all together instead of making swiss cheese out of one and only D-file? just imagine if you need block of data accessed by indirect addressing, one has to tip-toe around those artificially introduced holes. OUCH! this is nothing but example of someone in Japan being too lazy. - scan time of 82ms for 6000 step program - and that's on FX3U (i expected FX3 to be FAST, am i missing something? CJ1M for example is much better deal and it runs similar code in about 2ms) - communication in general is a complete mess. there is no single open protocol, then there is no single command to do the dirty work, instead, one has to handshake with remote device in plc code (grrr...) and on profibus one has to do the same just to handle consistency - plc code has to actively manipulate flags in BFM for each and every block (sent AND received) that is larger than 16-bit. this is nonsense. this is what people do when they develop for embeded system where development cost is offset by mass production of hardware. PLC is supposed to be pre-canned integrated system that should need minimal setup. - worst of all are the com port settings which are virtually undocumented (despite epic size manuals on serial comms) because they skipped the most important part. one has to read 10 such volumes to find bits and pieces on what the heck is default port setting, where to change it etc. - cannot use Device Test to set value to group of bits (like set value of K8M500 etc.). - FX plcs before FX3 don't allow addressing individual bits of the D memory (like contact with address D30.F).

[Sergei Troizky]

I worked with 3 generations of the FX-series for more than a decade until switched to OMRON few years ago. Never worked with FX3 and used Medoc up to the last day (and still use it on service calls). Never faced online edit problem similar to described by Goody. It is impossible to alter HSC declarations online, but such limitation for so called PLC Setup exists in all PLCs I know. Device set and mapping is a matter of getting used. Fully agree about D1000,2000,etc being ridiculous. Scantime never was a strong side of Mitsubishi. Being interpreters (not compilers) they have to scan even non-active code. Still, FX3U comparison with CJ1 is not correct, as these are different class PLCs. CP1 is much closer equivalent (still much faster than FX3U I guess). But could anybody explain me what good is data registers bit-level access? Well, except immediate detection of negative value. Edited April 14, 2009 by Sergei Troizky

[Crossbow]

How about if the register is a bunch of bits indicating different errors, not a number. This is quite common with analog modules. So checking a bit like D0.0 instead of checking the word for any odd numeric value or having to perform bit masking is a nice plus. I doubt the Omron PLCs are as much faster as you claim Sergei. I've worked with Omron and Mitsubishi and Siemens (S7-200), and to be perfectly honest, unless you're producing 6 million parts and hour, scan time is not a major issue on any of today's PLCs. They're way faster than they were even 5 years ago. And so many systems are still out there running 20 year old PLCs.

[Sergei Troizky]

I get your point about special modules and this is a common (and I would say the only) argument. But any PLC features one or another kind of word of bits (KnMx in Mitsubishi). I see no reason not to move the data register value into such word and naturally deal with bits as bits. CP1H is times faster than FX1N/FX2N. Times probably means 3, never measured exactly, but definitely not less. Never worked with FX3U as stated. Fully agree with the rest.

[Crossbow]

In old PLCs, you had to move the word to bits, and bits to words to transfer on networks and such. The bit within a word addressing saves all those wasted M bits. I've seen programs where 30 words were moved to bits. That's 480 wasted M bits.

[panic mode]

the problem with lack of bit addressing is with any type of decoding of communication data. if you have to access BFM, it is more efficient to do fewer transfers but handle more buffer registers. this also affects program length (one instruction instead of five for example) and fragmenting of the memory. say you get block of 20 registers, then you need to copy 3-4 of them to bit area so you can access bits individually (often just one or two are of interest so bunch of bits get wasted). FX plc has way more bits in D registers than what is available in M. also most of code is classic ladder instructions (use bits) so wasting M is something I try to avoid.