News:

  • May 21, 2026, 12:59:38 PM

Login with username, password and session length

Author Topic: Bug in FTPPUT  (Read 61 times)

Scot

  • Sr. Member
  • ****
  • Posts: 78
Bug in FTPPUT
« on: May 20, 2026, 11:58:41 AM »
This is going to be difficult to duplicate because it takes a long time, but I've had this same problem with multiple BRX units.

I'm using SD cards in a BRX to store log data that it pulls once per minute from several other Do-More PLCs. There's a lot of data so it's separated into 10 different CSV files.

Once per day at midnight it uses FTPPUT commands to upload each file one at a time to local FTP server.

Every few months, the FTPPUT commands just stop working and returning an error condition. The BRX can still successfully PING the FTP server but cannot execute an FTPPUT. If I power cycle the BRX, everything is working again. It requires the power cycle too. Changing to Program Mode and back to Run Mode doesn't fix the problem.

Maybe the FTPPUT command is not releasing file handles with the network device and eventually can't get a new handle? Not being the author, I don't know. But it seems to be a consistent time period before needing to be power cycled.

I have this system installed in 3 plants. The other 2 plants are newer and only have 2 files they upload each night. Those take much longer before needing to be power cycled. These are connected to the FTP server through the onboard ethernet port, not the POM ethernet addon.

MikeS

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 263
    • Host Engineering, Inc.
Re: Bug in FTPPUT
« Reply #1 on: Today at 08:52:00 AM »
DMLogger can be used to display some of the FTP traffic between the BRX CPU and the FTP Server. This is a high-level look at the CPU's interaction with the FTP Server - it's not as detailed as a wireshark trace - but it might tell us why the connection attempt is failing.

Run Debug -> Do-more Logger. Make sure to select the option to 'turn on ST36' and select 'Level2 - Update ERR and MSG' for the messaging level.

Once DMLogger is up, use the 'Change' button to set the 'Accepting Packets from' address to the BRX CPU you want to monitor.

Any time the FTPPUT instruction is executed you will see the interaction traffic displayed in the logger.

one caveat is this logging mechanism is generic, meaning that any instruction in the CPU that has logging capability will do so when the logger is activated, so depending on what else is happening in the program you'll see traffic unrelated to the FTPPUT in the logger.
Good design costs a lot. Bad design costs even more.

Scot

  • Sr. Member
  • ****
  • Posts: 78
Re: Bug in FTPPUT
« Reply #2 on: Today at 10:54:32 AM »
I did try that yesterday before power cycling the BRX. I turned on ST35, set messaging to level 2, and left the Logger set to receive packets from Any but it received no packets at all when retrying the FTPPUT command. That network was on a remote system that I have limited access to so I think the Logger was being blocked from network access. I was remotely connected to a local PC at the site but I think the Do-More Logger running on that PC was blocked by Windows and I only had a User login, not Administrator.

I will have to wait a few months before being able to test again with the local BRX which I know does work with the logger.
« Last Edit: Today at 10:56:07 AM by Scot »

MikeS

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 263
    • Host Engineering, Inc.
Re: Bug in FTPPUT
« Reply #3 on: Today at 11:42:02 AM »
i should have mentioned that the DMLogger does use network broadcasts to get data from the CPU to the Logger dialog, so yes, it does have to run on a local PC that can accept broadcast packets.
Good design costs a lot. Bad design costs even more.