Hello,
I found a strange thing with a scale that is transmitting data via RS-232 to the CSERI-4 module.
https://opto22.com/support/resources-tools/downloads/grv-cseri-4-module-firmware
Firmware 1.6f works fine, but when I upgrade to 1.6g, nothing comes through.
There looks to be about 4 years between these versions, but perhaps this may help someone else.
Cheers.
Grant
You should know better, @grant1. Once you install something, you never, ever touch the firmware again. Once it’s in production, it’s locked forever. Glad I could help. 
I have a few questions.
> Is the EPIC firmware also up to date? Old EPIC firmware may not be compatible/aware of new module firmware.
> Have you tried the module on another rack?
> Did you move the module slot? CSERI-4 doesn’t work in all slots.
> Have you seen the same issue with another CSERI-4 on firmware 1.6g?
> Could this issue be an intermittent issue that simply appears to be caused by the upgrade but is only a coincidence?
> Will you continue to elaborate? I may not have asked all the right questions.
Hope you can get some help very soon.
Sounds like you’re kidding a bit (and I’m aware of realities, although I can’t endorse not upgrading).
I have limited experience on the production side, but I am a long time GNU/linux user. I cut my teeth on Arch Linux about fifteen years ago, which is a rolling release distribution, as in there are no OS upgrades; every time packages are upgraded you have upgraded the OS. Arch Linux is a do-it-yourself GNU/linux distribution, so there were frequent breaking changes I had to address.
There are strategies for keeping up to date without having too much down time.
> Archive OS, packages, sources, firmware, and data. I have a back up of all the mainline packages in a GNU/linux distribution I used. You should certainly archive EPIC firmware and module firmware along with all your data.
> EPIC and RIO processor firmware can be downgraded! I don’t know whether you’re aware of such awesomeness! Keep in mind though, that module firmware is not downgradeble.
> Honestly, I’d keep spare modules in case one or two go out of commission. This is good practice.
> There’s the chance of corner cases not readily apparent or causing immediate problems. This is critical in industrial domains. For those, I hope you have a robust suite of tests, that can exercise out corner cases prior to going back into production.
> Opto 22 is an experienced, mature, and customer-focused tech company. Opto 22 is committed to keeping their products working. They have loooong product life cycles. If Grant’s issue turns out to be something Opto 22 can address, then there will very likely be an upgrade path in the future.
Of course the main blockades for staying current on EPIC OS/Module Frirmware are downgrades and hardware cost. Those are certainly a legitimate issues, but hopefully you have spare modules.
EDIT: The motivation for staying up to date is that all of the technology ecosystem moves forward. If you’re not prepared, you might need to upgrade (maybe due to needing to replace hardware), and you should be ready. A big jump forward is more difficult than incremental steps.
As with any technology, there are security updates that should be applied immediately.
Of course, the choice of upgrading is between you and your colleagues. You have all the knowledge of your business needs to make such a decision.
Is the EPIC firmware also up to date? Old EPIC firmware may not be compatible/aware of new module firmware.
Yes, it’s running the latest.
Have you tried the module on another rack?
Yes, same experience with different EPIC units.
Did you move the module slot? CSERI-4 doesn’t work in all slots.
Same experience so long as CSERI is placed in the first 4 slots of the rack (which we have always done).
Have you seen the same issue with another CSERI-4 on firmware 1.6g?
We have several units and saw the same pattern on all. It took us a while to figure out why it would not work on R1.6g
Could this issue be an intermittent issue that simply appears to be caused by the upgrade but is only a coincidence?
Does not appear to be related to anything other than the CSERI firmware. We updated our EPICs from v3.x to v4.x in May and this exercise spanned both of the EPIC firmware versions.
FWIW, we also used Node-RED (instead of PAC Control) to see if the RS-232 data would flow into the CSERI module and it did not as long as R1.6g was installed. Moving back to R1.6f solved the problem in both Node-RED and PAC Control (which is not really a surprise, but just shows that PAC Control config had nothing to do with it).
I’d put a scope on it with both firmware versions, especially since the only documented change is electrical termination per KB89222.
Hey grant1, I’m the engineer that built that firmware revision (not product support, sorry PSG if I’m jumping the gun, but this will probably hit my desk sooner or later anyway).
I can confirm this build had literally no other changes, only a single bit in a bitmask (and some build server/process differences, but we’ve QA’d/tested the firmware and build problems would have long been caught, if not in this module, in another using the same build system).
Now, that single bit was used to specify whether or not a bias resistor was active in RS232 mode. In RS485 mode, the bias and termination resistors are toggleable. In RS232 mode, the first firmware iteration left the bias resistor enabled. This was not an issue, as the RS232 chip drives the lines more than strongly enough to overcome this bias, and even with the bias, the modules were still within spec and consistently passing testing. An RMA tech caught this some time later, and ultimately we fixed it.
This makes me curious how your system is setup electrically. Was the bias counterbalancing some other part of your system? I’d be curious to hear what oscilloscope sampling finds,
Oh man! Feels like I kicked a hornet’s nest now 
We do not have an oscilloscope, which is what I believe you are asking for.
This Rice Lake scale is a strange bird in that it uses RS232 over the RS485 connections. Perhaps that is what makes the difference in this particular case? See p. 32 of the manual here: https://www.ricelake.com/media/hilhch3s/m_131128_sct20_tech_enus_revl.pdf
My goal is to get rid of the RS232 and get everything talking on RS485, but no time to play around with that yet.
No worries!
It sounds like that’s your problem, you happened to be the one lucky user who that bug was a feature for! It sounds like sticking with the old firmware for now is the right move for you (until you move over to RS485), but let us know if there’s anything else we can do to help!
Also, thank you for making the forum post! Users in the habit of reporting problems and providing details are something I and the other engineers (and I suspect customers) here are immensely grateful for!
I must correct what I said in an earlier post,
Keep in mind though, that *module firmware* is not downgradeble.
That seems to not be the case. Noted.