Seriously, though there is enough embedded/PLC coding going on that I imagine people still know what can be done with low clock rates, a simple instruction set, and some clever asm gymnastics. Ever end up scaling a analogue input by multiplying and discarding the low word of the result because the instruction set lacked and efficient DIV instruction? And if I'm that old, I'll go drown my sorrows in alcohol now!:)
I maintain a huge C++ codebase written by someone else. Pointers are no problem at all. The structures and classes they point to are all defined somewhere. The problem is, after loads of features tacked on randomly, the code has become unmaintainable. Core features break other core features and ugly hacks abound. Also Microsoft's OLE library breacks because the original coder did some extreme use case things that expose a long unfixed bug in modern OLE32.dll libraries. Working with code like this leads to the conclusion, that once understood, sometimes it is better to reimplement the whole thing building in all the core functionality from the base.
This has been my practical experience with fairly well written C++ code. Comming from an embedded angle, there should be no problem understanding what the code does, or the data it works on, but maintaining or extending it may be a lost cause.
I know. Still can't figure out how you guys manage it. I work with a professional Zimbabwean who did it without bribery. That was really difficult, but they aren't so harsh on professionals. Once you're in, it isn't too bad though. As for tax, well, ironically, SARS regularly exceeds its collection targets and they want to destroy the middle class with etolls. Fun times....
Aka devicenet. The problem is, these things aren't so bad with 12V or 24V next to them, but start adding strong signal sources from 220V (110V in america) power lines connected to nonlinear nodes and you will start to see why sheilding the comms from the power is a good idea....
Either you're a troll or a traitor to your own kind. But no matter if the latter, we can simply apply your own view to yourself - given the choice between saving your life and the life of any random human, we must not choose you. You are too ignorant of the subtle bonds that keep human beings in any semblance of order and progress as a species to be useful and therefore are completely expendable. Fortunately for you, you live in the western world, and even at your poorest you have had insane advantages over the poor here in Africa. Every one of them, whose life is worth far more than your own pathetic broken one. The sheer ignorance and stupidity that spouts this view is not worth saving. Best let it die. Or perhaps get a sense of proportion?
Still, I meet a lot of your countrymen here in South Africa, and they seem to be doing pretty well. How they got past our retarded BBBEE law I don't know... Our government is broken in different ways to yours.
RS485, you mean. RS422 has too many wires to make it worthwhile over any significant distance for the sort of network loads we're talking about. Also, you need shielded cable, which can become pretty expensive quickly. A lot of your average loads will really screw with serial comms on switch on. Nowhere near as bad as an industrial VSD. Oh, wait, they're starting to put those into washing machines... Yeah, you need shielding these days.
I'm actually comparing cost... Diesel is about R1 (US$0.10) cheaper than petrol year round over here. Added to the l/km it is a no brainier, which is why I'm kicking myself for buying a petrol car, that is outperformed by even the cheaper diesels...
Except, if this were the case, how would your spare key work? Removed from the vehicle, it will not roll over..
I am not an expert here, but I suspect there is some two way communications going on. The vehicle asks for for code number x, which the key must supply correctly sort of thing.
I don't know, a colleague of mine has a BMW 320D, and that thing is insanely fast and quick off the line. Also efficient. Not quite a full blown sports car, but still a lot of fun to drive, if you can ignore the turbo lag... But still, for your average commuter a small diesel vehicle is far better than a petrol one. In something like a diesel hatch back, "a bit more efficient" translates to more than twice as efficient, and those have small turbos, so the lag is negligible. My sample size is small, but that is comparing a petrol Hyundai i20 to a Peugeot 307.
While I was taking the piss, that doesn't fly. If you want torque and don't want to sacrifice fuel economy, get a turbo diesel, add a low range gearbox and diff lock for offroad. Diesels are brilliant, have masses of torque at the low end and are normally far more efficient than their petrol counterparts. A little expensive to fix when they break though....
The error counts that are part of the API and indicates framing errors. The returned data is full of '?' bytes in fairly predictable but not always consistent places(so not really random I guess...) in the packet, which is, again consistent with what the API tells me will happen on a framing error. The device only functions at 9600 baud and below. I was tempted to try at 300 baud, but I can't justify too much time in this.. Still I would be interested to know how the heck this happened....
The same code to sign on to the device (my code is transport agnostic) works flawlessly over a 4 port MOXA ethernet to serial device. The signon sequence (which I can't detail, as I am under an NDA - foolish of the manufacturer, but not under my control) proceeds correctly until the device returns a long packet (off the top of my head, more than 10-15 bytes). Smaller packets(5 bytes and less) seem to be fine.
Come to think of it, I did have a similar problem under.NET with a Tinsley resistance bridge, which also forced baud and bitrate settings on me, but that device is used on a moxa, so it didn't worry me too much either, though I strongly suspect the.NET serial API has a weird bug in it that only manifests under certain settings. I must check if the Tinsley used the same settings, but it occurs to me it probably did. I suppose I could bridge out the serial port and see if I can receive what I send correctly. It could also be that windows doesn't pick up the handshaking pins fast enough and so looses some bits? I haven't dug that deeply into the low level UART implementation in a quite while, but I would have expected that to be firmware controlled. I should also try it with a virtual comm port as opposed to a TCP pipe.
This is a weird one. The laptop in question(I couldn't be bothered to try a different machine) communicates flawlessly with the device through everything except.NET, where it writes correctly but reads a response full of random framing errors. It isn't an encoding or a settings issue, since I'm using the same settings as my C++ 6.0 library does, and the write would fail(which means the device would not respond). The device in question is half duplex. I don't design protocols anymore, just implement them.
No idea what went wrong here, and yeah, I would love to have looked at this under a CRO, but I no longer have access to one, and it was honestly simpler to revert to a TCP/IP driver to a standard ethernet to serial unit. I have met some insanely awful protocols in my time, but this is one of the better ones. CRCs, byte counts, standard packet formats, ACKs and NAKs and so forth. Each packet has metadata, so confusion is hard. All standard 7 bit ASCII. I suppose I could write a C# wrapper for a C++ function to read the serial device, but only one user is still using direct serial, and even then, it is a virtual comm port, so I can get around it.
[rant]Worst people for protocols are the makers of Lab and Test equipment. Apart from the Japanese, these tend to be universally bad, with often a write only setup on the instrument. How do you know it has been written? "Just assume it has." How do I know the device is on? "Start a test and wait for data. Or look at the light." I name no names... [/rant]
Your fellow AC addresses this nicely. I know exactly what I speak of, and I can not have a jury rigged nightmare mess sitting in a professional quality industrial panel. I would much rather have a proper adapter to start with.
Probably broken by design, but sometimes you have to work with what has been specified. In general, all devices seem to work correctly with ethernet to serial and physical serial adaptors (except if you try to talk via Microsoft's.net serial libraries which weirdly introduce random framing errors). USB to serial is always a toss up. Sometimes it works, often it won't.
I would really hate to have to deal with those boards, or even the massive relay logic banks that they used to use. You do have my sympathy....
I have worked with a lot of PLCs, but never action logic. Always curious, how do they compare to the Allen Bradleys and Omrons of the world? I am not tied to any particular setup, except I do have an abiding hate for the bloated mess that is Siemens.
And 9 out of 10 USB to serial adapters I have run into can't even generate the correct pin voltages... +/- 6V might work for some devices, but not all. A lot won't see anything below +/-12V. Especially the 'comms powered' type.
Slashdot Mirror
Hell no. That has no place in any industrial/control system. Especially not if safety is any concern at all.
Sounds like a modern Toshiba PLC....
Seriously, though there is enough embedded/PLC coding going on that I imagine people still know what can be done with low clock rates, a simple instruction set, and some clever asm gymnastics. Ever end up scaling a analogue input by multiplying and discarding the low word of the result because the instruction set lacked and efficient DIV instruction? And if I'm that old, I'll go drown my sorrows in alcohol now! :)
Your sense of humour chip is malfunctioning. You need to go in for repairs immediately.
I maintain a huge C++ codebase written by someone else. Pointers are no problem at all. The structures and classes they point to are all defined somewhere. The problem is, after loads of features tacked on randomly, the code has become unmaintainable. Core features break other core features and ugly hacks abound. Also Microsoft's OLE library breacks because the original coder did some extreme use case things that expose a long unfixed bug in modern OLE32.dll libraries. Working with code like this leads to the conclusion, that once understood, sometimes it is better to reimplement the whole thing building in all the core functionality from the base.
This has been my practical experience with fairly well written C++ code. Comming from an embedded angle, there should be no problem understanding what the code does, or the data it works on, but maintaining or extending it may be a lost cause.
It isn't usually such a bad assumption here... My apologies.
I know. Still can't figure out how you guys manage it. I work with a professional Zimbabwean who did it without bribery. That was really difficult, but they aren't so harsh on professionals. Once you're in, it isn't too bad though. As for tax, well, ironically, SARS regularly exceeds its collection targets and they want to destroy the middle class with etolls. Fun times....
Aka devicenet. The problem is, these things aren't so bad with 12V or 24V next to them, but start adding strong signal sources from 220V (110V in america) power lines connected to nonlinear nodes and you will start to see why sheilding the comms from the power is a good idea....
Either you're a troll or a traitor to your own kind. But no matter if the latter, we can simply apply your own view to yourself - given the choice between saving your life and the life of any random human, we must not choose you. You are too ignorant of the subtle bonds that keep human beings in any semblance of order and progress as a species to be useful and therefore are completely expendable. Fortunately for you, you live in the western world, and even at your poorest you have had insane advantages over the poor here in Africa. Every one of them, whose life is worth far more than your own pathetic broken one. The sheer ignorance and stupidity that spouts this view is not worth saving. Best let it die. Or perhaps get a sense of proportion?
Cheers.
Still, I meet a lot of your countrymen here in South Africa, and they seem to be doing pretty well. How they got past our retarded BBBEE law I don't know... Our government is broken in different ways to yours.
RS485, you mean. RS422 has too many wires to make it worthwhile over any significant distance for the sort of network loads we're talking about. Also, you need shielded cable, which can become pretty expensive quickly. A lot of your average loads will really screw with serial comms on switch on. Nowhere near as bad as an industrial VSD. Oh, wait, they're starting to put those into washing machines... Yeah, you need shielding these days.
You have obviously never worked with a PROM. Fellow poster is correct.
This rates interesting, but I have no points today...
I'm actually comparing cost... Diesel is about R1 (US$0.10) cheaper than petrol year round over here. Added to the l/km it is a no brainier, which is why I'm kicking myself for buying a petrol car, that is outperformed by even the cheaper diesels...
Makes sense...
Except, if this were the case, how would your spare key work? Removed from the vehicle, it will not roll over..
I am not an expert here, but I suspect there is some two way communications going on. The vehicle asks for for code number x, which the key must supply correctly sort of thing.
I don't know, a colleague of mine has a BMW 320D, and that thing is insanely fast and quick off the line. Also efficient. Not quite a full blown sports car, but still a lot of fun to drive, if you can ignore the turbo lag... But still, for your average commuter a small diesel vehicle is far better than a petrol one. In something like a diesel hatch back, "a bit more efficient" translates to more than twice as efficient, and those have small turbos, so the lag is negligible. My sample size is small, but that is comparing a petrol Hyundai i20 to a Peugeot 307.
While I was taking the piss, that doesn't fly. If you want torque and don't want to sacrifice fuel economy, get a turbo diesel, add a low range gearbox and diff lock for offroad. Diesels are brilliant, have masses of torque at the low end and are normally far more efficient than their petrol counterparts. A little expensive to fix when they break though....
The error counts that are part of the API and indicates framing errors. The returned data is full of '?' bytes in fairly predictable but not always consistent places(so not really random I guess...) in the packet, which is, again consistent with what the API tells me will happen on a framing error. The device only functions at 9600 baud and below. I was tempted to try at 300 baud, but I can't justify too much time in this.. Still I would be interested to know how the heck this happened....
The same code to sign on to the device (my code is transport agnostic) works flawlessly over a 4 port MOXA ethernet to serial device. The signon sequence (which I can't detail, as I am under an NDA - foolish of the manufacturer, but not under my control) proceeds correctly until the device returns a long packet (off the top of my head, more than 10-15 bytes). Smaller packets(5 bytes and less) seem to be fine.
Come to think of it, I did have a similar problem under .NET with a Tinsley resistance bridge, which also forced baud and bitrate settings on me, but that device is used on a moxa, so it didn't worry me too much either, though I strongly suspect the .NET serial API has a weird bug in it that only manifests under certain settings. I must check if the Tinsley used the same settings, but it occurs to me it probably did. I suppose I could bridge out the serial port and see if I can receive what I send correctly. It could also be that windows doesn't pick up the handshaking pins fast enough and so looses some bits? I haven't dug that deeply into the low level UART implementation in a quite while, but I would have expected that to be firmware controlled. I should also try it with a virtual comm port as opposed to a TCP pipe.
This is a weird one. The laptop in question(I couldn't be bothered to try a different machine) communicates flawlessly with the device through everything except .NET, where it writes correctly but reads a response full of random framing errors. It isn't an encoding or a settings issue, since I'm using the same settings as my C++ 6.0 library does, and the write would fail(which means the device would not respond). The device in question is half duplex. I don't design protocols anymore, just implement them.
No idea what went wrong here, and yeah, I would love to have looked at this under a CRO, but I no longer have access to one, and it was honestly simpler to revert to a TCP/IP driver to a standard ethernet to serial unit. I have met some insanely awful protocols in my time, but this is one of the better ones. CRCs, byte counts, standard packet formats, ACKs and NAKs and so forth. Each packet has metadata, so confusion is hard. All standard 7 bit ASCII. I suppose I could write a C# wrapper for a C++ function to read the serial device, but only one user is still using direct serial, and even then, it is a virtual comm port, so I can get around it.
[rant]Worst people for protocols are the makers of Lab and Test equipment. Apart from the Japanese, these tend to be universally bad, with often a write only setup on the instrument. How do you know it has been written? "Just assume it has." How do I know the device is on? "Start a test and wait for data. Or look at the light." I name no names... [/rant]
I still don't understand how you Americans manage to get such little power out of such massive engines... :P
Good point... You would need two way comms to get into most PLCs...
Your fellow AC addresses this nicely. I know exactly what I speak of, and I can not have a jury rigged nightmare mess sitting in a professional quality industrial panel. I would much rather have a proper adapter to start with.
Probably broken by design, but sometimes you have to work with what has been specified. In general, all devices seem to work correctly with ethernet to serial and physical serial adaptors (except if you try to talk via Microsoft's .net serial libraries which weirdly introduce random framing errors). USB to serial is always a toss up. Sometimes it works, often it won't.
I would really hate to have to deal with those boards, or even the massive relay logic banks that they used to use. You do have my sympathy....
I have worked with a lot of PLCs, but never action logic. Always curious, how do they compare to the Allen Bradleys and Omrons of the world? I am not tied to any particular setup, except I do have an abiding hate for the bloated mess that is Siemens.
And 9 out of 10 USB to serial adapters I have run into can't even generate the correct pin voltages... +/- 6V might work for some devices, but not all. A lot won't see anything below +/-12V. Especially the 'comms powered' type.