28 replies to this topic

[TravisT]

I am looking at using netduino to communicate with our hardware and a modbus system. Has anybody used any modbus libraries NModBus in particular. http://code.google.com/p/nmodbus/ I am assuming that it would be coded exactly or almost exactly like a desktop app but want to confirm that. Any help or examples would be appreciated. Thanks!

[Mario Vernari]

Hi Travis. I'd have implemented yet, but the RS485 interface requires a precise timing for the TX-Enabled line. There's no way to do it, until a custom driver written in C++ will be added to the framework. I don't know if there is another simpler way. Mario

[CW2]

I'd have implemented yet, but the RS485 interface requires a precise timing for the TX-Enabled line. ... I don't know if there is another simpler way.

IMHO simpler way would be to utilize the existing RS485 mode of the USART, for example by adding a 'mode' property to the SerialPort class or to derive a new class. It would require change in the firmware: setting the USART_MODE field of the USART mode register (US_MR).

[Mario Vernari]

IMHO simpler way would be to utilize the existing RS485 mode of the USART, for example by adding a 'mode' property to the SerialPort class or to derive a new class. It would require change in the firmware: setting the USART_MODE field of the USART mode register (US_MR).

You're right, but it also depends on how you'd like to implement the RS485 driver.
The Modbus spec says that you must use precise timing pre- and post-message. I took a look at the MCU specs, but it's not enough what it embeds.
By the way, even RS485 specs let you hold the linee with pull-up resistors, that is a very-economic way to solve the noise immunity. We have a long experience on very-noisy environments (with several meters of cable) and the resistors aren't absolutely enough. We are using taking the like busy some time before and after the message, so that the receiving uart can detect the real message with very few probability of errors.
Cheers
Mario

[fileark]

I am also interested in Modbus, specifically having the Netduino be a Modbus slave via ModbusTCP. This eliminates the serial issues but I am a novice at the Modbus protocol so I am not sure what would be involved, the master application would connect to the Netduino via IP address and TCP Port number then, using Modbus commands, requests read/write data. Any thoughts or discussion on how this could be done or limitations of the Netduino that I may not be aware of? Any direction would be appreciated. Thanks!

[Mario Vernari]

This is a task that I want/must to realize. Please, stay tuned! Cheers

[dougY]

i too am tasked with implementing RS485. currently i am trying with sparkfun's BOB: http://www.sparkfun.com/products/10124

but am experiencing many headaches. you know how it goes. you fight it for awhile then move to some other area of your project to help yourself feel like you are making progress.

right now it is working intermittently for me. i have sent data from Netduino+ to the BOB and seen it in hyperterminal (although dropping last byte somehow)
i have also sent data from hyperterminal to the netduino where it drops the first byte. kinda figuring something is not kosher there and its most likely the link between the keyboard and the chair.

the modbus/RTU device i try to talk to sends back 1-2 bytes of junk on a query. again not always reproducibly.
when i hook the device straight to a USB/RS485 and use the manufacturer's software it works well with no ill effects.

thinking there was a chance my shoddy soldering may have damaged the BOB. it looks ok, but i am running out of ideas as to where the problem is and am contemplating buying another one.

anybody have any suggestions?

[Mario Vernari]

DougY, I don't think your BOB is damaged, but simply the Netduino is not properly configured to drive such a shield. As in the posts above, the main problem is how to enable the TX-Enable (TXE) line during the transmission. Bear in mind that the RS485 is a half-duplex protocol. It seems that the MCU implements something about the RS485 mode, but it's not Modbus compliant. To have the line driven accordingly, the following sequence should be respected: the SLAVE is ready to receive data, thus the TXE must be inactive; the MASTER begins the transmission by activating the TXE line; the MASTER waits for a period equivalent to about 3.5 bytes; the MASTER sends all the data to the SLAVE; the MASTER waits for a period equivalent to about 3.5 bytes; the MASTER begins to listen to the SLAVE's answer, by disabling its TXE; ...and so away... The ideal handshake would be when the RS485 channel is always busy either from the master or the slave. That is really important when you have a medium/long wiring and/or a noisy environment. Finally, about the BOB of Sparkfun. That shield is much like a simple circuit to test the software, far from being reliable even in a pretty favor environment. It's a common practice to use an isolated driver (i.e. with optocouplers). Cheers PS: I ported the NModbus TCP for the .Net MF almost at all, but I still haven't the chance to test it.

[dougY]

thanks for the input mario. i believe i am setting the RTS correctly with one of the digital IO pins. setting that pin to true before sending the request turns on the little light on the BOB. after setting it to high, then sending the 8bytes of the request, i set it to low and then sleep 5ms and await a response that never comes. as for the optocoupler suggestion, is that really the trick? do you know of any other shields or BOB's i could try? I am thinking about possibly walking over to the engineering college nearby and paying a grad student to do this for me. but before i go that route i wouldnt mind tinkering a bit more on my own. .cheers.

[Mario Vernari]

Doug, you should connect a scope and check the signal timing. I suspect that the RTS timing is not correct. It is not because you, but because it's almost impossible to rely on the timing of the Netduino. There's no guarantee about the real delay, not the exact sequence of the operation (I mean the physical output of the bytes). Cheers

[dougY]

mario, unfortunately i dont have a scope. do you think that adding a breadboard with an optocoupler may help me out? those chips seem pretty cheap, but i dont know where to start looking. going to mouser, i see literally thousands of them. have you used any of these that you could make a recommendation? what about this one from sparkfun: http://www.sparkfun.com/products/314 or the 4-channel one they sell: http://www.sparkfun.com/products/784 and i think maybe these forums need a "buy user a beer" button so i can somehow pay you back for your advice. thanks, doug

[Mario Vernari]

Hi Doug. Thank you so much for the "beer" (although I don't like it!). It does not matter: here is a bunch of friends playing for fun/hobby or whatever else. This is for me a job as well, but our products are for industry-grade, so they are much more complex and expensive of course.
I really like hardware and software, since my childhood...this is only my real passion.

The opto-coupler is not mandatory, unless you will use the RS485 wiring along many many meters and/or noisy environs (bad grounding, electromagnetic emissions, big electric motors, etc)
From our long experience we learn that the most damaged part of a industrial system is just the RS485 interface. We always supplied with opto-coupler because is much more robust. By the way, when the wiring is 50-100 meters long, it is easy to have faults and blown during storms, for lightnings falling in the nearby. Lightnings are somewhat hard to protect from.

So, don't be in a hurry and wait before purchase any opto. You may do it later.

The RS485 driver is maybe the very first thing I tried to do with my Netduino, but it was totally unsuccessful. The Atmel chip has a "RS485 mode" itself, but it seems not allowable using the current framework. We should write a custom driver, but this is another (sad) task, hard to sort out.
Anyway, even the "RS485 mode" won't solve the goal.
The Modbus specs requires a precise timing before and after the byte stream. That is hard to reproduce, because the slowness and the background stuffs the framework has to do.
I guess there are only three solution for the Modbus with Netduino:

• someone will write a RS485 lo-level driver (using C/C++) and include it in the firmware;
• someone will create a "shield" hardware custom made for the RS485 RTU interfacing (so maybe the opto-couplers are embedded);
• avoid the RTU and use the TCP: that's the actual way I'm going to try.

IMHO, the first choice will never happen due to the few people interested in.

You may also search for someone will borrow you a scope to check the signals, but once you have see they don't match the standard...what shall you do?
Cheers

[dougY]

ouch. it does not sound like there will be much chance of my success :^( but i am gonna go ahead and get the opto chips. i figure even if they dont solve my rs485 problems i still can use them for hooking up some relay circuits for another fun little project. and i dont think modbus/TCP is really an option for my application. since the 485 device is off the shelf and RTU its not worth it to mess with designing that. maybe its time i consult the guys over at the engineering college which is 5 blocks from here. too bad its summer and not too many of them are around.

[Firegun]

Hello guys, I´m entering in one new project that Modbus would be a realy nice plus. What I´ve imagined to do is try to implement it over UDP, witch would solve those timing problems, what u guys think about it? And other question, how would Netduino Plus behave in a industrial env? Would it last for at least 2 years, without problems? (considering it would be safe from energy spikes or stuff like that). Would the NModbus fit my intentions? Can it be used with .NET MF ?

[Mario Vernari]

Hello Firegun. I don't think the UDP would be a good choice, because it is not reliable. Moreover, I guess that there's no UDP support by Netduino. The TCP should going fine: is supported, and the Modubus/TCP is a well-known standard (de-facto). As you read above, I tried to port the NModbus, but it was sooooo far from a working Micro Framework implementation, that it cannot be named so anymore. Once again, shame on me, because I have still to test... About industrial env... Well, the N is not targeted to work in industrial environments, but it also depends on what you mean...if you are looking for temperature range, certifications and whatever else, I guess Netduino is NOT the right choice. On the other side, if the reliability is not a primary issue, and you are going to use a Netduino along some other good hardware (spikes protection, isolated I/O, etc), maybe could fit. We are developing industrial smart-sensors and regulators. Our target are heavy/hard/dusty environments, and the game is hard to play. The quality/reliability is important, thus the price rises as well. I personally am studying whether a small device as Netduino could be used in some way...at the moment, however, there are too many problems. Cheers

[pugtech]

CuteDigi has an RS485 shield that might help. I haven't tried one yet. http://www.cutedigi....roducts_id=4500

[Firegun]

The TCP should going fine: is supported, and the Modubus/TCP is a well-known standard (de-facto).

Yeah, I´ve noted this after a bit more research...

About industrial env...
Well, the N is not targeted to work in industrial environments, but it also depends on what you mean...if you are looking for temperature range, certifications and whatever else, I guess Netduino is NOT the right choice.
On the other side, if the reliability is not a primary issue, and you are going to use a Netduino along some other good hardware (spikes protection, isolated I/O, etc), maybe could fit.

I´m not expecting a very heavy env, we planning in automate a lime mixer, there is no much to do (control 2 servos and watch 2 potentiometers, maybe 3), but they want to be able to control it in place and from distance, that´s why we´ve turned into Modbus idea, but it could be archived with another approach, just that Modbus is a standard way to do it.

My question on the industrial env is cause we can expect to have they running all days for long periods, it is much more cheaper then a CLP, and can do a great work on that project (I think at least). It will be inside a closed box and behind electrical protection for supply and I/Os for sure, it´s more a question on the durability, and stability I think. I don´t wanna then to be hanging after some hours of work, or need to change then after 6 months.

Looking at it´s components, I think the N+ don´t have much to be damaged (just by regular use), maybe the voltage regulators? Idk ... advises are vry welcome

[Mario Vernari]

First question: are you in a hurry? I.e. could you consider thinking on within one month? If you don't need a real-time device, Netduino could fit, I think. The case protection is surely a good point, as well as an electrical interfacing. Noise, shocks, long wiring may compromise the reliability of the system. The only prevention you can't affort is about the temperature, but maybe that's not an issue. I'd seriously consider some kind of watchdog, independent to the Netduino itself. It could be a simple monostable circuit (NE555 o similar), that must be cyclically reset, otherwise will reset the whole board. Moreover, if the safety of the served system is an issue, you should provide some way to "neutralize" a strange behavior of the Netduino. You may do it providing some hardware trick protecting from a Netduino driving crazy. For instance, if you were a heater and the Netduino will hang with the heater on, a safety trick would be detaching automatically the heater when it's on for a longer period. Well, none is talking about this argument. IMHO, these small devices running Micro Framework, Java or else will have a serious impact even on the industry in the next decade. The scada world is changing! Cheers

[Firegun]

First question: are you in a hurry? I.e. could you consider thinking on within one month?

No, I´m not in a hurry, we still planning on do that, checking if it will be a good idea to do it that way... but why? you made me curious

I'd seriously consider some kind of watchdog, independent to the Netduino itself. It could be a simple monostable circuit (NE555 o similar), that must be cyclically reset, otherwise will reset the whole board.

I´ve liked this idea, good one

Moreover, if the safety of the served system is an issue, you should provide some way to "neutralize" a strange behavior of the Netduino. You may do it providing some hardware trick protecting from a Netduino driving crazy. For instance, if you were a heater and the Netduino will hang with the heater on, a safety trick would be detaching automatically the heater when it's on for a longer period.

Here we will do it the right way, with an emergency button that will shut things down in a "hardware" manner, avoiding any possible craziness from the software

[Mario Vernari]

No, I´m not in a hurry, we still planning on do that, checking if it will be a good idea to do it that way... but why? you made me curious

I am pretty busy, but I wish to complete my modbus/tcp porting. Once it will be working, you may use it.

Here we will do it the right way, with an emergency button that will shut things down in a "hardware" manner, avoiding any possible craziness from the software

I don't mean an "emergency" context, rather an hardware solution to keep the controlled system "safe" when the Netduino is out of service (no power for instance).
It's common to provide a "system-halt" when the controller is off, otherwise the behavior could be unpredictable.
Cheers