Wiring looks good; lines are terminated… And the Physical View’s IF1 Configuration shows these?
Two coding topics stand out as strange to me:
We know the device needs to communicate using Modbus RTU. From the look of the terminal output, this device uses the ASCII mode rather than the RTU mode. Why do we use the DVFrame library instead of the DRV_mbus library?
If you want to stay with the DVFrame library (which I personally had a hard time getting to work for some reason), the xopenConfig already has two delimiters available – the only change we need to make is the value of “delimc”. Why are we trying to manually append terminating characters to the buffer?
Many people swear by the DVFrame library. Let’s just say I don’t have as much success using that library as using DRV_mbus. (For example, @corne.geerts says delimc/delim[0]/delim[1] are only used for receiving data – I wouldn’t know because I never got that far in using DVFrame. And when I read the help document, delimc seems to apply to both outgoing and incoming frames.)
The DRV_mbus has sample code that you can import, just like the DVFrame library.
For your use case, I might suggest that you
Change Master.S1 to TRUE and not use the line “MBMOpen_0.pConfig := ADR(‘datamod’)” (In other words, only use the MBMCmd function block in the sample code)
Change MBMOpen_0.ascii to 1, because your device seems to be taking commands in the ASCII mode.
Change “MBMCmd_0.data := ADR(LibDRVmbus.LocalPV4[0])” to the address of a STRING variable. Then try writing ‘PL1’ or ‘PL0’ – with terminating characters if necessary – into that STRING variable.
Oh, and run a trace of the MBMCmd_0.status variable to see what error the function block may be reporting.
Before you try the DRV_mbus library sample, can you trace your FRM_writeAcknowledged_0.status variable to see if that function block returns any error code briefly beside the constant 65535?
it’s an interesting idea to use the modbus library instead of DV_Frame, I’ve never tried this together with the usecase to send a raw string / raw data.
Therefore I’ve some questions to your remarks:
I can’t see anywhere a hint that the device is a modbus RTU device?
By the terminal screenshots it looks like a raw data transmission without any more control protocol, and as I know modbus is a control protocol that uses so called function codes and registers to transfer data? So isn’t it mandatory that the slave then also uses the modbus protocol?
About the delimiters of DV_Frame:
until now, I agreed with @corne.geerts that the frame delimiters are only used when receiving data. The reason is that incoming data is collected by the drivers internal memory, until some idle time without receiving new data is reached or special characters (the frame delimiters) are received - then the driver “knows” that one received packet is finished, and returns the whole consistent data of the packet via the buffer.
When sending data via DV_Frame, the whole data is given to the driver at once, so there’s no need for a “packet consitency flow control”). Would be very cool if the delimiters are automatically appended to the packet data, can you please point out the help information about that? Thanks!
can you please check if you have the latest firmware and Automation runtime running?
If not, could you please update:
PLC firmware
PS firmware
Automation Runtime
Unfortunately I don’t have the same hardware, but I played around a bit and I had some issue where I’m not sure where it’s coming from. After updating firmwares and AR to the latest versions, I looked better at my test.
These are the versions I used, but als I said: it’s not exactly the same hardware, so maybe versions differ.
I also stripped down the sending routine in my tests to a minimum needed to make the code better readable:
I don’t use the internal buffer handling
opening and closing the interface in INIT and EXIT
only calling FRM_writeacknowledge in cyclic
Here’s my test program, I was able to receive the data sent on a 2.nd RS485 interface (which was also a B&R interface card of type X20CS1030). RS4Send.zip (1.5 KB)
But like mentioned in the post before: it worked after upgrading all firmwares and AR, before upgrading I also had issues with sending / receiving (I’ve not investigated them further).
PROGRAM _INIT
FRM_xopen_0(enable := TRUE, device := ADR('IF1'), mode := ADR('/PHY=RS485 /BD=9600 /PA=N /DB=8 /SB=1'), config := 0);
END_PROGRAM
PROGRAM _CYCLIC
IF bSend = FALSE THEN // avoid to change send buffer if sending is active, because I don't use the internal send buffer mgmt!!
IF bSetOn = TRUE THEN
sCommand := 'PL1$r$n';
ELSE
sCommand := 'PL0$r$n';
END_IF
END_IF
IF bSend = TRUE AND FRM_xopen_0.status = 0 THEN
FRM_writeAcknowledged_0(enable := TRUE, ident := FRM_xopen_0.ident, buffer := ADR(sCommand), buflng := UDINT_TO_UINT(brsstrlen(ADR(sCommand))));
IF FRM_writeAcknowledged_0.status <> 16#FFFF THEN // keep calling FB every cycle until status != BUSY
// ok or error
bSend := FALSE;
END_IF
END_IF
END_PROGRAM
PROGRAM _EXIT
IF FRM_xopen_0.status = 0 AND FRM_xopen_0.ident > 0 THEN
FRM_close_0(enable := TRUE, ident := FRM_xopen_0.ident);
END_IF
END_PROGRAM
Oh, Mea Culpa! I worked through another post that had asked about Modbus comm, so when I saw RS485 here I automatically assumed it was also doing Modbus RTU and in the ASCII mode. That was a bad assumption on my part.
every feedback is valuable! So don’t blame yourself, same thing happened to me many times and for sure will happen again in future
Thanks for your reply, so I can stop thinking about what I’ve overseen
we are getting somewhere !!!
i can turn on the device with PL1$r$n
then the status goes to 65535 , but no turning OFF
i think this will be some parameter of speed settings
Indeed FRM_writeAcknowledged changes its state from busy to error or ok, if a frame was ensured transmitted.
To be honest, I don’t know how this is ensured internally; maybe by receiving something on the interface, also maybe (especially when using half-duplex busses like RS485) by sensing “special combinations” of the data lines voltage / preambles / “footers”? In my test case, I haven’t sent anything back from the receiving interface, so at least I can confirm that a individual data response is not needed to change the busy state to done.
Maybe it’s worth a try to switch back to FRM_write - FRM_write does not check if data was really transmitted and received, it “only” puts the send data to the driver’s buffer, and the driver itself tries to transfer the data asynchronous.
Using FRM_write also means, that I don’t know when data was really sent, so normally I should use the DVFrame internal buffer handling. But for the test if the behavior changes, I only replaced FRM_writeAcknowleged to FRM_write - could you try if it works then?
